BTCPay Server 2.0: Megathread

[NicolasDorier]

This is a mega thread to track everything that should be cleaned up for BTCPay Server 2.0:
Could use project milestone, but at this stage this is more of a brainstorm.

• The Big Cleanup: Refactor BTCPay internals

Deprecations and Cleanups

Beta Give feedback

1. Remove Checkout v1 Remove CheckoutV1 #5906
2. Cleanup the AddressInvoice table from non on-chain data (Cleanup AddressesInvoices table #5905)
3. Remove MySql/Sqltite depedency (Remove MySQL and Sqlite deps #5910)
4. Remove any migrations code older than 2020 (Remove migrations prior to 1.0.3.162 #5939)
5. UI: Move section navigation to sidebar #5744
   Discussion Enhancement UI / UX +3
   
6. Remove Guest role
7. Cleanup uppercase/lowercase inconsistencies in POS metadata and receiptData
8. Update status field of Invoices to not use legacy bitpay's status, but the BTCPay native one
9. Decoupling PaymentMethodId from Payouts with PayoutMethodId Decouple PaymentMethodId from PayoutMethodId #5944
10. Rename *PaymentData to *PaymentDetails
11. VACUUM (ANALYZE) as part of the migration to 2.0
12. Cleanup data such as old expired invoices logs
13. Removing periodicity of pull payments (Remove period concept from PullPayment #5963)
14. Removal of some DB column that aren't needed #5903
    2 of 3
    +0
15. Use of GIN index for invoice search rather than separate table
16. Remove docs on https://docs.btcpayserver.org/Development/Theme/#checkout-page-themes ([MERGE AFTER 2.0] Remove docs on customizing checkout page btcpayserver-doc#1385)
17. Onchain: Introduce pending transactions (Multisig/watchonly wallet transaction creation flow proof of concept #5743) as new concept/layer between transaction creation and signing
18. Onchain: Abstractify hot wallet signing to service so that we can support various new modes (such as remote signing via app)
19. Convert payjoin receiver to use the payjoin receiver nuget lib to allow more complex workflows through plugins
20. Refactor onchain support to be similar to LN (connection string style, allows plugins to provide their own onchain tracker system instead)
21. Cleanup all [Obsolete] declarations
22. Migration of Payouts

Pluginization

Beta Give feedback

1. Move Bitpay integration as system plugin
2. Make ZCash support an external plugin
3. Make system plugin enableable/disableable
4. Add test for migration of Monero payments
5. Move boltcard code/schema as a plugin (alongside with the bolt card factory stuff)

Optional / Nice to have

Beta Give feedback

1. Remove direct dependency of NBXplorer (allow an LN only instance for example)
2. Introduce modifiable Server roles ( allows users without store creation for example)
3. Convert various UIs to Blazor
4. Convert Dashboard to Blazor
5. Merge -LN and -LNURL payment methods
6. Allow topups on pull payments
7. Allow extensions to add fields to Receipts (Proof field got removed in The Big Cleanup #5809)
8. One payment method config can create several payment prompts? @Kukks
9. Remove Invoice Archival? (Seems to be used, ask @d11n)

[NicolasDorier]

Refactor onchain support to be similar to LN (connection string style, allows plugins to provide their own onchain tracker system instead)

@Kukks I believe it isn't possible. We are querying NBX database directly in SQL.

[pavlenex]

Convert various UIs to Blazor

Can we be more specific when listing issues, what does this mean?

[Kukks]

Convert various UIs to Blazor

Can we be more specific when listing issues, what does this mean?

I believe it is any UI that uses Vue currently. We can work on a list later

[pavlenex]

Alright, I understood this list should be a list of breaking changes, but it seems we're pilling quite a lot of things here, and I am trying to understand how to prioritize what is now becoming quite a massive list of tasks.

[ndeet]

2nd try, had written everything up got distracted and shut down the laptop, all gone 🙈

I have no access to tasklist so posting here for review and discussion.

API: inconsistent webhook event naming (breaking change)
We have InvoiceReceivedPayment and InvoicePaymentSettled, it would be more logical to have them aligned and change InvoiceReceivedPayment to InvoicePaymentReceived

API: Clean up store wallet docs
We have two sections in the navigation "Store Payment Methods (On Chain)" (SPM) and "Store Wallet (On Chain)" (SW), both use the same endpoint path (stores/{storeId}/payment-methods/onchain/{cryptoCode}/) and the listed endpoints are mixed up a bit.

1. SPM has the Create store on-chain wallet endpoint listed which better fits to SW
2. The response of above create wallet endpoint contains a legacy field which is not settable through above mentions endpoint called label that is always null on newer wallets
3. Discuss: Preveiw store on-chain payment method addresses and Preview proposed store on-chain payment methods should also be renamed and moved to SW as it relates to wallet and not payment method, if there is a reason to have it here then maybe move Get Store onchain-wallet address to have address fetching together in one section

API: Cleanup Apps / Crowdfund / PoS (possibly breaking change)

1. The "App" section has create/create/delete endpoints for both Crowdfund and PoS but their specific sections only 1-2 endpoints, either move everything to apps or to their specific sections
2. Update Crowdfund endpoint is missing (at least in docs)
3. there is only one general Delete App endpoint but not specific for crowdfund or PoS

I had a few other API related issues on my list but those inconsistencies have been already fixed.

Does anybody find the old BTCPay 2.0 megathread, afair there was one but I could not find it?

[ndeet]

API: Permission on Refund Invoice endpoint
The current permission is btcpay.store.cancreatepullpayments but it should imo be btcpay.store.cancreatenonapprovedpullpayments

[Kukks]

API: Permission on Refund Invoice endpoint The current permission is btcpay.store.cancreatepullpayments but it should imo be btcpay.store.cancreatenonapprovedpullpayments

I believe we can do this without a breaking change as it softens the permission

[ndeet]

API: Invoice refund inconsistency
With the pull payments endpoint you can set paymentMethods as an array and if not set it will apply all available payment methods, with the invoice refund endpoint you only can pass a string and it is required too.

Suggestion: Make it a nullable array too to be consistent and more flexible