Right now, the daemon parses CLI params and compares them with the default values provided. In the future, we must make it read stuff from a config file similar to how we read from the config file for other params. An extension would be to establish preference of CLI params over the hardcoded ones

right now, we store the seedpwd only when the user requests to accept a specific project investment. This is done to ensure we aren't custodians of money and similar. We should have an option where people who want to can store their seedpwds against a specific project. Should be easy to do, with an additional param in relevant fields along with an RPC for the option itself.

We should move the data from the April 2019 demo into a separate folder. This issue is meant to track progress towards that.

we have consts passed around everywhere, should arrive at a better solution to it. Will do after testing the investment flow on mainnet.

Due to some bug, the openx binary is huge at ~400MB. We need to explore and see what's causing this.

We should have three custom log levels - warning, error and debug. Warning should only print errors and fatal messages, Error should print warning, errors and fatal messages, debug should print log, warning, errors and fatal messages. Default should be warning since we don't want people to ignore errors and fatal messages. Should be doable with something similar to logrus but given logrus is a massive library to import, we could write our own library to implement custom methods.

Checklist to finish migration:

• Change repo name
• Setup Travis CI and codecov
• README updates

We should add Jenkins nightly build so we can dispense builds right away without issues

Right now, if the build fails, we silently fail the script and don't update the UI in any way. We either must report back to GitHub so we don't merge the PR or have something in the UI that says that the latest builds are failing.

We must add he necessary endpoints which are necessary for the KYC and stablecoin providers. Most of the bootstrap stuff is in already but we need to hook it up to the vendor's endpoints so we have that covered.

Intercom is a popular add-on used for chatting with platform admins or people who can offer support.

This seems to return an empty struct to the frontend which causes problems.

The email package seems to be broken, we might need to generate a new email password combination and check whether things work.

Stellar's testnet resets every 3 months and it happens to have reset just after we fixed our tests, so looks like we'd have to fix them again.

AnchorUSD does not need KYC if XLM is exchanged through the DEX to get USD. Using this USD, they can technically invest in the platform and there shouldn't really be anything that prevents them from being able to invest in projects.

On a code level, this should be easy, if the user already has USD, don't check for KYC and if the user doesn't, exchange for USD through the DEX. Depending on jurisdiction, this might not be allowed, so that's something to keep in mind as well.

Add a progress update endpoint

On signup, we currently don't send any email confirmation link. We should send one and not allow a user to login unless they confirm their email.

the RPC pre-request handling is weird now - it has multiple places where it writes stuff, we handle errors almost everywhere. This should be nicer and more standardised so people don't have to worry about this stuff while auditing code.

Admins must be public so that people can contact them in case they face something that they need to seek help for. The admin bool is also returned on querying a user, so this change would not be related to YaleOpenLab/openx-frontend#8. This change should be relatively easy since it involves writing an RPC endpoint and filtering users based on the admin bool.

Similar to kyc but this verifies if the user who just created an account on our platform is really who they claim to be. ComplyAdvantage does only KYC, so we'd need to verify their identity and then move on to kyc.

frontend issue: YaleOpenLab/openx-frontend#12

It would be a cool idea to generate backend code for a new custom platform based on params that a user passes. An example for opensolar is mainnet = true, chain=stellar and escrow=true. If a person wants al legacy system on bitcoin testnet for example, they would set mainnet=false, chain=bitcoin, legacy=true, escrow=false. Since openx contracts would be well audited, it is safer for people wanting to do custom platforms to use openx instead of rolling their own platform. Custom parameters can be added in - either to openx or to their platform instance (which must be open source due to GPLv3). Would be a cool and extremely useful feature to have.

Right now, the open architecture is quite interwoven and complex, and as a result, we must document it so its easier for people who are new to the project to take it up. This can be done as part of the integrate gitbook that we plan to create

Right now, investors can communicate with admins (since admin emails are available on a public endpoint) but there is no way for admins to message investors within the platform without them taking a look at private details of the investor (the investor ideally should not make his email public to avoid unsolicited emails). This should be made possible, either within the platform (to avoid emails leaking to admins) or outside.

Right now, people can request as many tokens as they want but there is only one token field. In the future, we might want to have a set of tokens that are valid at the same time. This can be set to five and we restrict the /token caller to wait for one of them to timeout before requesting a new one.

Right now, mainnet only supports AnchorUSD investments. We should add in XLM investments and use the DEX to convert b/w XLM and AnchorUSD if the base currency is in USD. Adding support for other base currencies is detailed in #222

Right now, we only have unit tests for components that are isolated in function from the others. For components who functionality is linked closely with others, unit tests can't help since one needs the other. For this, we would need to have integration tests that test the investment workflow, payback workflow, etc.

openx as is being developed right now is solely in the context of opensolar. In order for it to be more modular and a platform of platforms, things need to be de-contextualized and only openx functionality must be retained in this repo. Other stuff can be moved to the opensolar repo and we can start two daemons - one for openx and the other for opensolar (in order to run the opensolar frontend instance)

With the addition of the easyjson library, we must move over to the methods generated by it to gain the 4x speed boost that it provides us with. Shouldn't have the generated files in git since that would mask other changes that we make to other files. Will take this up.

Some applications might need an accessToken that lasts longer than usual and we should add an endpoint where it is possible to request such a token.

GitHub actions is native to GitHub and seems to be better than Travis in terms of integration with GitHub (which should be obvious I guess). Should explore it and chart out a workflow.

Link: https://github.com/marketplace/actions/golang-action

Currently, we return an error and as a result, the notification would never be sent. The ideal way is to send notifications to an admin and wait for their response. An addition would be to add the possibility for admins to trigger parts of the contract using their authority.

We should create a gitbook similar to that of openclimate to have a singular place of reference for all things openx.

Every time a new commit is pushed to master, we must hook it up with the build server to have the latest builds ready.

right now, we use a password based authentication scheme. This may be insecure in some use cases and apps requiring access have to create a dummy account on the platform before they can use this, so we should shift to an access token based scheme with timeouts. Also helps in seeing how many requests are made from specific accounts.

Now that we have nightly builds up and running, we should have a separate doc to distinguish those who are building from source and those who are running a binary.

Some projects might want to raise money purely in crypto - xlm / btc only for examples. Such investments might not need KYC (#218) and can be invested in by multiple people. There is no risk involved since we don't hedge against USD, the project's base currency is in crypto, so there are no conversions involved. Exchange of assets on the secondary market would also be interesting since a crypto native project can be used to hedge against a USD native project (and the other way around).

Now that we have nightly builds up and running, we should have a separate doc to distinguish those who are building from source and those who are running a binary.

currently, sweeping funds is restricted to XLM. In the future, we need to be able to have an order on the DEX that would enable us to exchange any asset for XLM and then sweep Xlm to the new address.

Github supports adding a FUNDING.yml file to display a "Sponsor" button along with the repo. Should add one so people who might want to tip something know how to.

Travis has been failing for a while - need to investigate and fix this so we can have deterministic builds.

some rpcs that are open right now must be closed and made admin only since they contain sensitive info (encrypted seed and similar). Will do along with #188

after the mainnet test is complete, we must move common endpoints to REST by redefining routes, having CRUD stuff, etc (most of our routes now are just GET requests)

We should have a frontend page where we can type in field names and values and it gives us back json. This would be easy for designers who can easily get json files for the data they've designed on the frontend.

should add some settings which would make switching to mainnet as easy as flipping a switch.

other platforms should have a set of API keys or similar in order to communicate with the openx platform. These API keys must be kept secret since they can allow anyone to represent the particular platform.

right now, our list of RPCs is a mess, it contains a big list of endpoints with no idea how many endpoints exist or what their params are. Must have an easier way of doing this to make writing API docs way easier.