peepin
peepin copied to clipboard
reply parser
- [ ] 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.
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 noparentIDproperty )peep-<CHILDIPFSHASH>( reply to peep )children-<ROOTIPFSHASH>( array of children of that IPFShash = [<CHILDIPFSHASH>] - for downwards traversal of the thread )