EndlessVanguard / bitcoin-remunerate-api

A scheme for trustless, decentralized, anonymous, remuneration for content creators.
1 stars 0 forks source link

Redis data store #7

Closed mattgstevens closed 8 years ago

mattgstevens commented 8 years ago

We should make the root element a hash, so we have unique redis key and don't scan the entire store.

structure is like:

{
contentData: {
  [ html, pdf, other URI... ]
}
contentBitcoinPayable: {
  {
    contentId:
    publicKey
    privateKey
  }
}
}
fromheten commented 8 years ago

Wording & naming

I'm not 100% sure what the word contentBitcoinPayable means - what do you think about naming it invoice? It is an invoice for a purchase of some content, with an account to pay to, amount to pay and all that.

Invoice is also the word BitPay uses in their API, and when I used it it made a ton of sense.

content structure

If the invoice collection is called invoice(s), we have the word "content" free to use! That would let us name the collection holding all the content content, which could be a data structure like this

{
  "mimeType": "text/html", // let's piggyback on this standard
  "content": "<h1>this is an article!</h1>"
},
{
  "mimeType": "application/pdf",
  "content": "... however the hell you write pdf ..."
}

Binary data

Havent used Redis for binary things, but it seems that the String type can handle binary data. We don't need to manipulate it - just host it. So it should be pretty easy. Although it might be better to host that on some file system rather than in the DB.

I read about it on the bottom of redis docs for data types

mattgstevens commented 8 years ago

100% on the naming; was trying to be smart and name things as what they represent.. but who knows if we will have other payments in the future :)

Seems like for small files / content payloads Redis will be ok if we keep some memory things in mind about how Redis types work http://redis.io/topics/memory-optimization