High level feature lists pages

[thunderbiscuit]

This PR adds pages that describe in words the complete list of functionality you can expect for each of the language bindings libraries. It's meant as a reference for developers "shopping" around for libraries and trying to decide what can be done with which tools.

Note that these 4 pages imply we should also write one for the core BDK library, but that one will be much more extensive, and I'm not sure I'd be comfortable writing it myself at the moment. This is roughly what the current PR looks like from the user's perspective:

[netlify]

✔️ Deploy Preview for awesome-golick-685c88 ready!

🔨 Explore the source changes: 0a8824a

🔍 Inspect the deploy log: https://app.netlify.com/sites/awesome-golick-685c88/deploys/621fd10899a8890008db1625

😎 Browse the preview: https://deploy-preview-89--awesome-golick-685c88.netlify.app

[notmandatory]

Had another thought on how to do this.. do it as you have, but don't repeat for each language we support. Instead use a single page of headers and following details but add some sort of badge like (rust) (kotlin) (swift) (python) you add after the header to denote which language supports it. for example:

Keys

(rust) (kotlin) (swift)

• Generate a BIP32 Root Key, with or without a passphrase, choosing from 12, 15, 18, 21, or 24 words.
• Restore a BIP32 Root Key (root xprv) from a set of 12, 15, 18, 21, or 24 word recovery phrase, including with or without a passphrase.

Or something like that...

[thunderbiscuit]

@notmandatory I can make something like this work:

[thunderbiscuit]

It's actually pretty neat. The only problem is that some features break into sort of subgroups, and it can get a bit messy. It might be just a matter of neatly stating the features. But for example right now in Rust bdk you can create a psbt with as many recipients as you want, but in the bindings you can only pick 1.

[thunderbiscuit]

Also exploring the idea of the table as discussed on Discord

:

It might turn out to be a bit of a long table... haha. Yeah not sure between all of these options. If anyone else has opinions on what they like/think can be useful I'm all ears.

[ConorOkus]

I've been trying to think this through a little bit, not sure if it's the right direction for these specific docs. Doesn't feel like it should be part of the main navigation, where I think the priority should be getting users up and running with code asap. Perhaps we speak more to using the API's themselves e.g descriptor, wallet, keys etc. and provide code snippets for each. Nav structure might look something like:

Descriptor

• Overview
• Supported Languages
• Rust
• Android
• iOS

Wallet

• Overview
• Supported Languages
• Rust
• Android
• iOS

Keys

• Overview
• Supported Languages
• Rust
• Android
• iOS

[danielnordh]

Having just discovered that some functionality is not available in the swift package, I would appreciate something like the table above to understand what is/isn't available per language.

[thunderbiscuit]

@ConorOkus I agree that code snippets for a bunch of small tasks would be super cool. I've seen it done with collapsible sections too inside the page itself, so it's neat because you can see all the sections/title for which snippets are available without the clutter and you can expand to see the code snippet itself one at a time.

As for what the intent of this page was, let me expand on the initial idea (which was originally here: #88)

The idea for this page started because I realized after speaking with someone that they weren't totally clear on "what you could do with BDK, say as opposed to rust-bitcoin" (let alone the fact that the bindings are a subset of the bdk lib), and I realized that it might be easy to just write it out in plain text, almost like a grocery list of things available to you as a dev.

Steve and I have been bouncing with this idea (happy to hear your thoughts as well); the main user of the page is maybe a product manager or a dev who's maybe shopping around for a library to do some bitcoin wallet stuff, and they're just not sure what exactly they can do with each. So for example on Android/Koltin you might be considering bitcoinJ, bdk-android, and bitcoin-kmm, but how can you quickly differentiate their feature set? This is that sort of page/thinking. No API docs, no code, just bullet points in plainish language of the things you can do with this library.

You said

not sure if it's the right direction for these specific docs. Doesn't feel like it should be part of the main navigation

Would you maybe put that sort of thing somewhere else? Should we have a section of the website or maybe just a new sidebar heading with more "meta" pages that don't have code and such? I think that could work well.

[ConorOkus]

@thunderbiscuit yeah sorry that statement was a bit blunt, but looking at the table layout as a nice overview seems reasonable tbh. Only "concern" is that is not contextual. If a feature is available in Swift for example there isn't any accompanying code snippets currently.

So I was thinking if it makes sense to reverse it and say here is the Blockchain Sourcing API with code snippets from all the supported languages, with tabs for each language like this - https://lightningdevkit.org/payments/connecting_peers/

[thunderbiscuit]

Did I close this? Sorry I don't remember. Anyway I do think we should keep iterating over this (although maybe in a completely different form, see #88). No matter what, we need a simple page that lays out nicely the range of things the library can do for you as an applications developer (our target developer audience).