kristerv / heliumpay-budgetweb-backend Goto Github PK

• Dockerfile-daemon
• Dockerfile-app
• docker-compose.yml
• Get heliumd and helium-cli to talk to eachother.
• create CoreOS server
• Deploy to server
• Also deploy frontend
• Where's nginx in all of this?
• Connect actual database
• Should probably test everything with dashd on a separate server just to be sure.
• Make the blockchain persistent

Overview

Users will need to browse active proposals. To avoid pulling from the cli on each request, a background process needs to be created that will fetched proposals every minute and sync them to the database.

This will also make the app more scalable since we can keep the background sync separate from the web servers.

Proposals will also need to be associated with a user so we will need to store that association.

Storing proposals will also let us generate a url-friendly slug based on the title to allow the frontend to present clean, memorable and seo-compatible urls: https://www.dashcentral.org/p/texas-btc-conf

API

GET   /proposals              -> all proposals
GET   /proposals?slug=:slug   -> proposals matching slug
GET   /proposals/:id          -> single proposal
GET   /proposals/:id/comments -> all comments for proposal

Schema

proposal
  id: pk
  slug: string # unique, case-insensitive, url-safe name (ie. heliumlabs.org/proposals/my-proposal-slug)
  hash: string # stores propsal.hash returned by the cli
  userId: fk -> user.id # owner
  title: string
  description: string
  ...

References

• https://stackoverflow.com/questions/10018100/identify-item-by-either-an-id-or-a-slug-in-a-restful-api

Templates: http://blog.mailgun.com/transactional-html-email-templates/

• Put up forum for discussions
• First payment and payment count BACKEND
• First payment and payment count FRONTEND

Why?

For accountability and security, most features require some sort of user context. A user identifies which actions are allowed to be performed on behalf of the client.

For example, features that would require a user context are:

• Commenting on proposals
• Saving meta data like masternode keys and using them to vote on proposals
• ... (See README for upcoming feature roadmap).

What?

Users will need to:

Create an account

Required fields for creating an account:

• Username
• Password
• Confirm password
• Email?
• Captcha?

Email, Captcha and PINs

DashCentral requires that the user fills in a Captcha. I'm assuming they do this to avoid spam and bots:

I'm assuming because they don't require that the user provide an email, they instead require a PIN. The user is required to remember and re-enter the PIN whenever they make an account change. I'm curious as to why they felt the need to have the extra security.

Requiring a PIN and Captcha seems to be the natural tradeoff for anonymity (at the cost of convenience).

Advantages to requiring an email means we likely don't need a captcha to prevent spam / bots or a PIN for account changes. We could also leverage a magic link to be sent via email instead of as password, simplifying the login process.

If our users are expected to be the same as DashCentral users then in may make sense copy the experience. However, Slack seems to be a popular gathering ground of our user base which requires an email and allows magic link in addition to password auth.

Login

Required fields for login:

• Username (or email)
• Password (or magic link)
• Reset password?

Account settings

Required fields for account settings:

• Email?
• Timezone?
• PIN?
• API Key?

Compared to DashCentral:

How?

Users will be able to register with a username / password. They can optionally provide an email for password resets. If an email is entered a confirmation email is sent. To prevent spam a captcha is required.

Even though username / password login is fairly trivial I think we would benefit from using a lib like http://passportjs.org/ for future authentication strategies.

For captcha, I suggest ReCaptcha by google: https://www.google.com/recaptcha/intro/android.html

Database

Table name

users

Schema

id: int (auto-increment)
username: string (unique)
password: string (bcrypt)
email: string (unique, nullable)
emailConfirmationHash: string (nullable)
emailConfirmed: boolean
... other fields that make up a user profile?

API

POST /v0/login { username or email, password } -> auth jwt
POST /v0/users { username, password, email? } -> new user
GET /v0/users/self -> verify jwt -> user profile for jwt.sub (username, email, ...?)
PUT /v0/users/self -> verify jwt ->{ email? } -> updated user for jwt.sub

[TODO]: Password reset

Currently causes a server error if trying to register a user with an existing email.

Also ignore empty string as email.

Overview

Users will need to able to comment on proposals proposals and vote on other users comments. They will also need to edit and delete their own comments. The proposed feature set is using dash central as a guideline.

API

GET   /comments?proposalHash= -> get comments for proposal # must provide a proposal
POST  /comments               -> new comment
        {text, proposalId, replyToId}
PUT   /comments/:id           -> update comment
        {text}
POST  /comments/:id/vote      -> new vote count
        {direction: -1 | 0 | 1}
DEL   /comments/:id           -> delete comment

Schema

comment
  id: pk
  userId: fk -> user.id # owner
  replyToId: fk -> comment.id # if set, is a reply
  text: string

comment_vote
  id: pk, fk -> comment.id
  userId: pk, fk -> user.id
  dir: int

References

• https://stackoverflow.com/questions/8112831/implementing-comments-and-likes-in-database
• https://stackoverflow.com/questions/192220/what-is-the-most-efficient-elegant-way-to-parse-a-flat-table-into-a-tree/192462#192462
• https://www.reddit.com/dev/api/#POST_api_vote

POST /login/sendPasswordResetEmail works off an email address but it should allow username to be provided as well. If a username is provided, the email is looked up from the users table. An error should be thrown if there is no email for the provided username.

ChildProcessError: stdout maxBuffer exceeded dash-cli gobject list (exited with error code undefined)

Invalid routes currently return html