Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reply parser #12

Open
5 tasks
sponnet opened this issue Aug 24, 2018 · 1 comment
Open
5 tasks

reply parser #12

sponnet opened this issue Aug 24, 2018 · 1 comment

Comments

@sponnet
Copy link
Owner

sponnet commented Aug 24, 2018

  • create basic parser
  • create JSON schema to validate input
  • save peep in local cache
  • look up related peep ( parentID ) in local DB ( what if related peep does not exist yet ? )
  • save reply thread info in DB ( parentID tree ) so that for any peep you can easily lookup its thread.
@sponnet
Copy link
Owner Author

sponnet commented Aug 24, 2018

Example reply payload:

{
    "type": "peep",
    "content": "Yes. Yesssss. ",
    "pic": "",
    "untrustedAddress": "0x94b26d7a0145635ed3dad4b786f47b6be4f3945a",
    "untrustedTimestamp": 1521521622,
    "shareID": null,
    "parentID": "Qmf4TMhyrqhRH8YtwdnzvrPU28pYVGtDTiix6zVzh8kKY2"
}

These payload are saved to IPFS and then the resulting IPFS hash is saved to the smart contract. This is the primary key that is used for creating the parentID relation.

So IMO the peeps are best saved using that same hash as the primary key.

In a key-value store these could be stored as follows

  • peep-<ROOTIPFSHASH> ( original peep - root of a thread - has no parentID property )
  • peep-<CHILDIPFSHASH> ( reply to peep )
  • children-<ROOTIPFSHASH> ( array of children of that IPFShash = [] - for downwards traversal of the thread )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant