search

hypha-dao / document-graph

EOSIO contracts for modeling a graph data structure with flexible data storage of each document
MIT License
10 stars 3 forks source link

npm package for document handling #5

Closed mgravitt closed 3 years ago

mgravitt commented 4 years ago

Document functionality will be needed in multiple places, including the Data Loader and the UIs. This functionality should be packaged into an npm package for easy re-use.

This functionality should include:

sebastianmontero commented 4 years ago

Hi, What is left to be done regarding this issue? Is it the get-current-version method? Has the fork functionality been implemented? What would be the inputs? The hash of a forked document?

Thanks

mgravitt commented 4 years ago

@sebastianmontero The smart contract needs to be updated to link documents together as graph edges. For example, an assignment should have a graph edge linking to the role and the member (and vice versa). Currently, the POC is translating the objects to documents 1-to-1 but it isn't adding these edges.

So the tasks here would be 1) updating the smart contract to create these on-chain, and 2) updating the graph schema to make it queryable.

And yes, also the get-current-version of forked documents.

Another requirement is to add certifications on-chain (based on proposal approvals), but this can be a subsequent step or included in this one.

sebastianmontero commented 4 years ago

@dappdever so at the moment the roles, members and other objects are also being stored as documents, correct? And so for example the assignment document should have an entry of type checksum256 pointing to the role, correct? Wouldn't this relationship be established in the client application while the assignment is being created?

mgravitt commented 4 years ago

@sebastianmontero Yes, exactly! Well, they are being stored as objects and ALSO documents. I think some/most of this connective logic should go into the smart contract. For example, an action for someone applying for a role would receive the role hash as a parameter, but then the smart contract would transform that into the right document(s), create the right ballots for the proposal, calculate compensation parameters, etc.

But there would also be more generic proposals, such as a new policy document, which is a more raw document that is just a proposal requesting to be certified by the DAO account.

My thought is to start with a few well understood edges, such as role-->assignment or member-->badge (upcoming type), to gain some experience and test queries, and then implement the remaining edges. Since we are creating the documents in parallel to the object structure, it gives us some flexibility on how we transition. As the queries become available, we can replace the on-chain object queries in the UI with dgraph ones.

sebastianmontero commented 4 years ago

@dappdever so which smart contract actions would be a priority? Do they already exist, and we only have to modify them to create the right documents? or have to be created from scratch?

mgravitt commented 4 years ago

@sebastianmontero We are implementing badges in the DHO, and I am implementing them as documents instead of objects. This might be a good starting point since we don't have to worry about migrating from objects for this.

For badges, there's a propose action that accepts a content_group vector, creates a document, creates a telos-decide ballot, and it adds a record to a docindex table under the proposal scope to indicate that a new proposal has been made.

Then, when the proposal passes, the hash in the docindex table is moved from the proposal scope to the badge scope. At that point, the documents table remains unchanged and docindex is only a link.

This is described in more detail, with the action and get table commands here: https://github.com/hypha-dao/dho-web-client/issues/87#issuecomment-705008751

What do you think of this? The next step is to define the process for badge assignment proposals. This would be proposing that a specific member receive a specific badge. Perhaps we include a docindex scope for member, and each member would be represented as a document, and that would have hashes that link to the badge documents.