marijanp
commented
1 year ago - [x] Please run typst-fmt so I can read this stuff on my wide screen.
- [ ] On that note, it looks like you're going to want to use tagref, so you can put that in the pre-commit hooks too.
- [x] If you're using the words "correct" and/or "correctly", then you're not actually writing the functional requirement. The point of the functional requirement IS to figure out what those words mean. So for example: Depositing an amount of tokens, where tokens >= MIN_AMOUNT should be accounted correctly. Could be:Depositing an amount of tokens, where tokens >= MIN_AMOUNT results in a new balance: the sum of the previous balance and the amount.
- [x] [tag:F00-04] When a user submits a deposit request, the request cannot be used more than one time without the users approval. I'd drop the "without the users approval". The user can just make another deposit request.
- [ ] [tag:F01-00] Withdrawing an amount of tokens, where users L2 account balance >= tokens > MIN_AMOUNT should be accounted correctly. I'm not a fan of using mathematical formulae as parts of a sentence like that. You know my opinion on this so I'll voice it once and then shut up about it: It's easier to read a document when you can replace any formula with "yaddayadda" and still have sentences make sense.
- [x] I don't like using "should" (moral language) in specifications: There's an RFC that describes which language you can use in specifications: https://datatracker.ietf.org/doc/html/rfc2119. I recommend using that because it's very standardised.
- [x] [tag:F02-03] Transfering a valid amount to another user that does not have a egistered L2 account yet should be possible. It's not clear what valid means.
- [ ] [tag:F03-03] Account balances should be updated immediately after th.... think what you mean to describe is that querying doesn't involve dirty reads. "Immediately" is vague and it doesn't need to be.
- [ ] Nit: The tags could have more descriptive names instead of numbers.
- [ ] The L2 node should not be monolithic but rather obey the principle of separation of concerns to allow for easier extensibility and replacement of components in the future. I'll voice this once and then shut up about it: Premature distribution is a recipe for integration hell. You probably want to keep pieces together as much as you can until you need to move away from that.
- [ ] Meta-note: I think there's a good opportunity to make as many interactions idempotent as possible. Idempotence is a great property for an API because it means you can retry as much as you want.