moneybutton / yours-core Goto Github PK

It needs to be possible to run two instances of Datt where each peer connects to the other and they can share data. We do not necessarily need a working rendezvous server and we do not need to support more than two users at the same time (although there's no reason why our code should be deliberately limited to two users).

There will be various "actions" a user can perform on a piece of content, such as paying the content or flagging it as inappropriate. We don't need to support flagging for MVP, we need to support payments. Note that because payments are on the blockchain, we don't really need the payment itself to be listed here, but we somehow need to communicate which person made the payment. An easy way to do this is to just record the payment in the database along with a signed message from the person who paid. We could also consider putting usernames in OP_RETURN, however long-term we won't be using normal bitcoin transactions at all, but rather transactions on a payment network. So having an action type for "payment" seems like the simplest thing to do for now that is also forwards-compatible.

Datt will make use of "signing the latest blockhash" to prove a signature is recent over and over. For now, we don't need to do this for real, but we need to at least mock up the latest block information which we can use throughout the app. Later, we can replace this with properly updated information.

The current transaction builder is very immature and may not be good enough for our uses.

At the present moment there is "user" information and "content" information in the database in a unique format - we need to document this and keep the docs up-to-date.

The easiest method may simply be to put the hash directly on the object like a normal property. We need access to the hash too frequently to have to recalculate it all the time. Another option is to put it on DBContentAuth, or perhaps a new structure, MsgContentAuth.

It should be possible to establish connections using PeerJS using a browser to itself with the (yet to exist) ConnectionBrowserWebRTC class.

There are some cool things you can do with object literals in ES2015, including making an object like {var1, var2, var3}, at least some of which are supported in node 4.0. We should update the entire codebase to make use of these features and then stick with them from there on out.

We're using node 4.0 and babel, both of which support arrow functions. Promise .thens and callbacks should all be arrow functions. We need to update all appropriate instances throughout the entire codebase to use arrow functions, and then use them exclusively where appropriate from then on.

Sometimes we want to convert a buffer into a crypto object, such as a public key or an extended public key, or our own objects like ContentAuth, but we don't want the to/from methods to block. Unfortunately some of the crypto in the to/from methods do block, such as converting a compressed public key into a pubkey object. We need to create non-blocking methods for these objects.

• Anything that involves compressed public keys should have an alternative that uses uncompressed public keys, because converting to/from uncompressed does not do elliptic curve math and thus does not block.
• BIP32 extended public keys and private keys have the same issue, plus they also have a checksum in string format.

Each piece of content needs:

• Title
• Body
• Signature
• Unique bitcoin address for this content piece to which to send payment

We should use the 0th account of a BIP44 wallet to generate new addresses, and keep track of the latest index we have used. We need to be able to plug a new, distinct address into new pieces of content.

It should be possible to create new "original content" which gets posted to the "front-page". We don't need to support multiple different categories for the prototype - just one "page" of content, the "front-page". Not that original content must involve signing the latest block hash to prove the content is new, to prevent users from spamming old content from other users.

We need to be able to show content right away, not just because it is nice when you see your own content, but I'm pretty sure solving this will allow us to see content that other people post immediately. Perhaps this is an appropriate time to start using events.

It needs to be possible to send a new piece of content to a peer that the user has authored.

It needs to be possible to send proof-of-payment to prove that a user has paid to a piece of content.

It should be possible to user your master key to sign your username.

We need to take components like "bitcoinbox" and put them in their own file, and then write tests for them, exactly like we have for the files in lib/*.js. The test framework works on our react components already - we just need to actually write tests.

Although long-term we desire SPV in a browser, unfortunately that is very complicated and the state of software that does SPV in a browser is immature. We are better of for now to use a blockchain explorer. btcd has an optional address index when you can use to get UTXOs. And of course, you can also use it to broadcast transactions. This will worrk for a prototype.

Right now there is some information about what the msg data structures are in dattdocs, however they are not an accurate reflection of what is actually in the code. We need to either put some documentation in this repo, or update dattdocs to be accurate.

Right now we're using a hex version of bip32 keys to send them to/from works and store/retrieve from database. Unfortunately this is a blocking operation because converting compressed pubkeys to a pubkey requires elliptic curve math. We need to implement asynchronous to/from JSON methods so this stuff doesn't block. When we do this, we could also consider using base58check instead of hex, which is the standard way to represent bip32 keys (xprv/xpub).

Use BIP 44.

A message type for asking a peer what content it has

We need to be able to create a transaction spending bitcoin to the bitcoin address in a comment. We do not yet need to worry about splitting the money between user, curator, node, etc.

We can save a few lines of code by using the new class notation. Like any other style decision, we need to do this everywhere or not at all, so we really need to update the entire codebase at once to do this.

It needs to be possible to ask a peer what recent content it has and to retrieve that content

There is a problem with error handling in the gulp file where when you run "gulp serve" if you get some kind of syntax error where browserify doesn't compile, browserify bundling the files. So we need to make the error handling work correctly so that when there is an error you can just fix the error and refresh the page without having to end gulp serve and rebuild everything.

It needs to be possible to send recent content to a peer. Long-term we may want to send hashes which can them be retrieved independently. For now it may be simpler to just send the content directly, i.e. send the titles of the front-page along with their bodies, which may or may not be displayed.

When you set your name, this creates a new msgauth which can be broadcast to peers. MsgAuth is based on ContentAuth. We should save this content to the database, so that we can display it on the front-page if desired.