• Write more of the documentation in JSDoc
• Auto-generate readable HTML out of JSDoc
• Publish synced docs online

Inspiration:

• http://localforage.github.io/localForage
• https://0xproject.com/docs/0xjs

See Server.gatewayUri parameter

Probably using https://github.com/ameensol/pg-ecdsa

canClaim must recalculate hash, that is signed by a sender. Now one could reuse a hash that is not related to channel or paid value to claim funds.

• Use settlement period for the channel
• Monitor the channel for the changes

Sender, receiver, or owner can delete a settled channel.

What if a channel is really stalled?

Unify wording between two

• Move to PouchDB or LevelDB
• Set database as a parameter
• Ensure it still works in browser

• Send total: current value + increment
• Track paid amount on the server
• Track paid amount on the client
• Close the channel if paid more or less than expected

Receiver: recipient, seller

Both must be used in "CAN CHECKS" methods.

If minimum channel amount is not set, use default x10 formula.

• pry for getting info on a resource cost
• see open channels
• close channel
• see status of the channels

getState, getUntil, and other getters to get an info on channel by its id

File that gives an error: https://gist.github.com/ukstv/bb2915784dfe7102eca1c599018f0aaa

It results in

Error: ENOENT: no such file or directory, rename 'machinomy~' -> 'machinomy'

Reason: Machinomy tries to open few instances of storage with every method call, like https://github.com/machinomy/machinomy/blob/master/index.ts#L134, https://github.com/machinomy/machinomy/blob/master/index.ts#L157 and so on.

Related NeDB bug report: louischatriot/nedb#320

Proposed fix: initialise storage once per instance.

CC @djKooks

"So if an attacker attempts to drain the contract of funds or an asset, it can trigger a decentralized response like locking them out and notifying other people who use the contract that they may need to withdraw their funds," he said.

• Save the channel
• Reuse it for incremental payments
• Close, when there are no funds left
• Reopen when there are no funds left, or no channel

• Track payments
• Close channel when the last payment is made

machinomy configuration invokes configuration manager CLI

Something like machinomy setup for an initial configuration

In isPaymentValid we should also check the signature on the payment.

Hi! Great project. Some of the docs do not make sense, though.

For example these parts in the getting started guide:

It would allow her to cheat by settling on a value less than sent one. The sender initiates channel settling by the same machinomy close command. The get the funds a receiver is expected to finish settle on her side.

There are probably some more, but not ones I have noticed as of yet. Generally, it is a bit confusing that you switch between using seller/receiver and sender/buyer in the same passage of text throughout the documentation. Settling on just one would make things a bit clearer.

Expose code in a package as ES5, while enjoying all the benefits of TS.

Disallow multiple channels between the same guys.

• Single database file
• Proper database schema for tokens, channels, payments

• Send 4xx error code
• Accept the error code and display gracefully
• Remove the channel on "Channel is removed" signal

Manage deployment there using Truffle.

Simpler invocation of Client class: just account address

Prevent negative payments.

machinomy buy http://example.com/resourcebuys the resource.