casey / casey/flow

Prognostication

Open
#7 0 comments 0 reactions 0 assignees View on GitHub
type: discussion
Dominant language
Rust
Stars
1
Forks
2
PR merge metrics
No merged PRs in 30d

Description

Users have needs that we can't anticipate, so it's probably ideal to get flow into people's hands–even Flow developers!– and always build the software with a mind for users and use cases.

Since people working on Flow already build and run it, we should use ourselves as guinea pigs.

After that, people who are already getting paid in crypto might find Flow to be a nice upgrade. We should probably look to onboard whole teams and businesses as units, since Flow is of no use to an employee if their employer doesn't use it.

Later and most challengingly, we can try to bring it to people without access to banking, functioning justice systems, dispute resolution, and communications infrastructure.

See issue #2 for potential platforms. I suspect that which platforms we target first will be informed by our real and potential users.

An potential initial roadmap for functionality might be:

- Basic streaming payments: A continuous stream of payments, attempting to hit a given satoshi per second target, with no underflow.
- Contracts: A notion of a contract for payment stored by the payer and payee. Upon activation by the payee, the payer begins streaming payments. Optional limitations and conditions can be implemented as needed.
- Daemon so payers can respond to contract activation at any time.
- Simple client so payees can activate and audit contracts.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.