|
1 | 1 | # 0.3.16
|
2 | 2 |
|
3 | 3 | * Set the BTC network in the identity and check, if the persisted network is the same as the one configured in the application, failing if it doesn't.
|
| 4 | +* Nostr npub as primary key in Nostr contacts (breaking DB change) |
4 | 5 |
|
5 | 6 | # 0.3.15
|
6 | 7 |
|
7 | 8 | * Upload and download files to and from Nostr using Blossom
|
8 |
| - * Add `nostr_hash` to `File` (breaking DB change) |
| 9 | + * Add `nostr_hash` to `File` (breaking DB change) |
9 | 10 | * Fix MintRequestResponse return type
|
10 | 11 | * Bill Caching for multiple identities (breaking DB change)
|
11 | 12 |
|
12 | 13 | # 0.3.14
|
13 | 14 |
|
14 | 15 | * Minting
|
15 |
| - * Added notifications and offers |
16 |
| - * Added timestamps for status |
17 |
| - * Call mint endpoint for cancelling |
18 |
| - * Use mint nostr relays from network and fall back to identity ones |
19 |
| - * Add endpoints to accept, or reject an offer from a mint |
20 |
| - * Add logic to check keyset info, mint and create proofs |
21 |
| - * Add logic to recover proofs if something goes wrong |
22 |
| - * Add logic to check if proofs were spent |
| 16 | + * Added notifications and offers |
| 17 | + * Added timestamps for status |
| 18 | + * Call mint endpoint for cancelling |
| 19 | + * Use mint nostr relays from network and fall back to identity ones |
| 20 | + * Add endpoints to accept, or reject an offer from a mint |
| 21 | + * Add logic to check keyset info, mint and create proofs |
| 22 | + * Add logic to recover proofs if something goes wrong |
| 23 | + * Add logic to check if proofs were spent |
23 | 24 |
|
24 | 25 | # 0.3.13
|
25 | 26 |
|
26 | 27 | * Minting
|
27 |
| - * Add default mint configuration options |
28 |
| - * `default_mint_url` |
29 |
| - * `default_mint_node_id` |
30 |
| - * Implement `request_to_mint` |
31 |
| - * Add minting status flag to bill |
32 |
| - * Add endpoint to fetch minting status for a bill |
33 |
| - * Add logic for checking mint request status on the mint |
34 |
| - * Add cronjob to check mint requests |
35 |
| - * Add endpoint to cancel mint requests |
| 28 | + * Add default mint configuration options |
| 29 | + * `default_mint_url` |
| 30 | + * `default_mint_node_id` |
| 31 | + * Implement `request_to_mint` |
| 32 | + * Add minting status flag to bill |
| 33 | + * Add endpoint to fetch minting status for a bill |
| 34 | + * Add logic for checking mint request status on the mint |
| 35 | + * Add cronjob to check mint requests |
| 36 | + * Add endpoint to cancel mint requests |
36 | 37 | * Change bitcoin addresses and descriptor to p2wpkh
|
37 | 38 | * Suppress logging from crates we don't control
|
38 | 39 |
|
|
48 | 49 | * Remove the `bcr-ebill-web` crate
|
49 | 50 | * Use a list of Nostr relays everywhere, instead of a single one, including in the config
|
50 | 51 | * Add Blank Endorse Bill data model implementation
|
51 |
| - * Rename `IdentityPublicData` to `BillIdentParticipant` |
52 |
| - * same for `LightIdentityPublicData` |
53 |
| - * Introduce the concept of `BillParticipant`, with the variants `Ident` and `Anon` |
54 |
| - * `Anon` includes a `BillAnonParticipant` |
55 |
| - * `Ident` includes a `BillIdentParticipant` |
56 |
| - * Use `BillParticipant` in parts of the bill where a participant can be anonymous |
| 52 | + * Rename `IdentityPublicData` to `BillIdentParticipant` |
| 53 | + * same for `LightIdentityPublicData` |
| 54 | + * Introduce the concept of `BillParticipant`, with the variants `Ident` and `Anon` |
| 55 | + * `Anon` includes a `BillAnonParticipant` |
| 56 | + * `Ident` includes a `BillIdentParticipant` |
| 57 | + * Use `BillParticipant` in parts of the bill where a participant can be anonymous |
57 | 58 | * Add the possibility to add anonymous contacts
|
58 |
| - * They only have Node Id, Name and E-Mail as fields |
59 |
| - * E-Mail is optional |
60 |
| - * This changes the data model for contacts, `email` and `postal_address` are now optional |
61 |
| - * Additional validation rules ensure the fields can only be set for non-anon contacts |
62 |
| - * Adds an endpoint `Api.contact().deanonymize()` to de-anonymize a contact by adding all necessary fields for a personal, or company contact |
63 |
| - * It takes the same payload as creating a contact and fails for non-anon contacts |
| 59 | + * They only have Node Id, Name and E-Mail as fields |
| 60 | + * E-Mail is optional |
| 61 | + * This changes the data model for contacts, `email` and `postal_address` are now optional |
| 62 | + * Additional validation rules ensure the fields can only be set for non-anon contacts |
| 63 | + * Adds an endpoint `Api.contact().deanonymize()` to de-anonymize a contact by adding all necessary fields for a personal, or company contact |
| 64 | + * It takes the same payload as creating a contact and fails for non-anon contacts |
64 | 65 | * Add the possibility to add an anonymous identity
|
65 |
| - * They only have Node Id, (nick)name and E-Mail as fields |
66 |
| - * E-Mail is optional |
67 |
| - * Adds an endpoint `Api.identity().deanonymize()` to de-anonymize an identity by adding all necessary fields for a personal identity |
68 |
| - * It takes the same payload as creating an identity and fails for a non-anon identity |
69 |
| - * Anon identity can't issue bills, or create a company |
| 66 | + * They only have Node Id, (nick)name and E-Mail as fields |
| 67 | + * E-Mail is optional |
| 68 | + * Adds an endpoint `Api.identity().deanonymize()` to de-anonymize an identity by adding all necessary fields for a personal identity |
| 69 | + * It takes the same payload as creating an identity and fails for a non-anon identity |
| 70 | + * Anon identity can't issue bills, or create a company |
70 | 71 | * Add the possibility to issue and endorse blank
|
71 |
| - * New `Api.bill()` methods for blank endorsements |
72 |
| - * `issue_blank` |
73 |
| - * `offer_to_sell_blank` |
74 |
| - * `endorse_bill_blank` |
75 |
| - * `mint_bill_blank` |
76 |
| - * Can issue (non-self-drafted) blank bills (payee is anon) |
77 |
| - * Can endorse/mint/offer to sell to anon endorsee/mint/buyer |
78 |
| - * If caller of a bill action is anonymous in the bill, any action they take stay anonymous (e.g. endorse) |
| 72 | + * New `Api.bill()` methods for blank endorsements |
| 73 | + * `issue_blank` |
| 74 | + * `offer_to_sell_blank` |
| 75 | + * `endorse_bill_blank` |
| 76 | + * `mint_bill_blank` |
| 77 | + * Can issue (non-self-drafted) blank bills (payee is anon) |
| 78 | + * Can endorse/mint/offer to sell to anon endorsee/mint/buyer |
| 79 | + * If caller of a bill action is anonymous in the bill, any action they take stay anonymous (e.g. endorse) |
79 | 80 | * Add endpoint to check payment for singular bill
|
80 |
| - * `Api.bill().check_payment_for_bill(id)` |
| 81 | + * `Api.bill().check_payment_for_bill(id)` |
81 | 82 | * Fix TS type for identity detail
|
82 | 83 | * Return identity on `create` and `deanonymize` identity for consistency
|
83 | 84 |
|
|
88 | 89 | * Reduce size of the WASM binary
|
89 | 90 | * Fix a small issue, where bills were recalculated instead of taken from cache, once their payment/sell/recourse/accept requests expired
|
90 | 91 | * Change behaviour of request to pay
|
91 |
| - * it's now possible to req to pay before the maturity date |
92 |
| - * The actual payment expiry still only happens 2 workdays after the end of the maturity date, |
| 92 | + * it's now possible to req to pay before the maturity date |
| 93 | + * The actual payment expiry still only happens 2 workdays after the end of the maturity date, |
93 | 94 | or end of the req to pay end of day if that was after the maturity date
|
94 |
| - * the `request_to_pay_timed_out` flag is set after payment expired, not after the req to pay expired |
95 |
| - * The waiting state for payment is only active during the req to pay (while it's blocked) |
96 |
| - * Afterwards, the bill is not blocked anymore, can still be rejected to pay and paid |
97 |
| - * But recourse is only possible after the payment expired (after maturity date) |
98 |
| - * An expired req to pay, which expired before the maturity date does not show up in `past_payments` |
| 95 | + * the `request_to_pay_timed_out` flag is set after payment expired, not after the req to pay expired |
| 96 | + * The waiting state for payment is only active during the req to pay (while it's blocked) |
| 97 | + * Afterwards, the bill is not blocked anymore, can still be rejected to pay and paid |
| 98 | + * But recourse is only possible after the payment expired (after maturity date) |
| 99 | + * An expired req to pay, which expired before the maturity date does not show up in `past_payments` |
99 | 100 |
|
100 | 101 | # 0.3.9
|
101 | 102 |
|
|
130 | 131 |
|
131 | 132 | * Add in-depth tests for bill validation
|
132 | 133 | * Add recourse reason to `Recourse` block data
|
133 |
| - * (breaks existing persisted bills, if they had a recourse block) |
| 134 | + * (breaks existing persisted bills, if they had a recourse block) |
134 | 135 | * Added `has_requested_funds` flag to `BillStatusWeb`, indicating the caller has requested funds (req to pay, req to recourse, offer to sell) at some point
|
135 | 136 | * Added `past_payments` endpoint to `Api.bill()`, which returns data about past payments and payment requests where the caller was the beneficiary
|
136 | 137 |
|
|
142 | 143 | * Add bill action validation for incoming blocks
|
143 | 144 | * Add signer verification for incoming blocks
|
144 | 145 | * Add recourse reason to `RequestRecourse` block data
|
145 |
| - * (breaks existing persisted bills, if they had a request recourse block) |
| 146 | + * (breaks existing persisted bills, if they had a request recourse block) |
146 | 147 | * Move bill validation logic to `bcr-ebill-core`
|
147 | 148 |
|
148 | 149 | # 0.3.2
|
@@ -172,7 +173,7 @@ can be passed - a list of file upload ids, to upload multiple files for one bill
|
172 | 173 | * Restructured `BitcreditBillWeb` to a more structured approach, separating `status`,
|
173 | 174 | `data` and `participants` and adding the concept of `current_waiting_state`, to
|
174 | 175 | have all data available, if the bill is in a waiting state.
|
175 |
| - * Added the concept of `redeemed_funds_available` on `status`, to indicate if |
| 176 | + * Added the concept of `redeemed_funds_available` on `status`, to indicate if |
176 | 177 | the caller has funds available (e.g. from a sale, or a paid bill)
|
177 | 178 |
|
178 | 179 | # 0.3.0
|
|
0 commit comments