Add ⚡️ content to `Getting Started` > `Technology Primer`

[Bosch-0]

A first step we can take with integrating LN in the guide is creating a 'Lightning technology primer' and rename Technology primer to 'Bitcoin technology primer.' When talking technology It makes sense to separate these concepts BUT when talking about design considerations / product we should intertwine the content. See thread here as to why.

We should also explain what 'Layer one / on-chain' means in 'Bitcoin technology primer' so these two pages are connected.

Some suggested 'Lighting technology primer' sections:

• What is Lightning?
• How is Lightning different from layer one?
• What is a payment channel?
• What is a Lightning balance?
• What is a Lighting payment?
• What is a Lighting node?
• What is BOLT?
• What is a Lightning network implementation?
• Lightning network whitepaper

[sbddesign]

I really like the idea of a Lightning technology primer. However, I wonder if the last 3 bullet points are too much detail for an early chapter in the Guide.

I am not sure that understanding BOLTs, LN implementations, and the LN whitepaper is going to be the most important information for designers that are interested in working on LN wallet. I worry about overloading the reader with such technical information early on.

For example, in the current Technology Primer, we do not talk about Bitcoin Improvement Proposals, we do not talk about different implementations of Bitcoin node software, and we only briefly mention the whitepaper.

I'd suggest some of this more advanced LN content be put in the Glossary, or perhaps we just link to other sources for readers who want to dig deeper.

[Bosch-0]

I am not sure that understanding BOLTs, LN implementations, and the LN whitepaper is going to be the most important information for designers

I wouldn't say we go into detail but just briefly explain what they are (just a paragraph or so) and link to external sources for deeper dives. I think understanding what a BOLT and BIP is, as well as which ones exist, is very important to designers. It helps us know what UX is possible and what is likely to come in the future. I don't think they are very complex things to understand on a surface level.

For example, in the current Technology Primer, we do not talk about Bitcoin Improvement Proposals, we do not talk about different implementations of Bitcoin node software,

I reckon we should for reasons above tbh.

Understanding that different implementations can and do exist is something that imo is also important to designers. It is more so important for Lightning where multiple implementations are used as whether you choose LND, Eclair or c-lightning for example the product possibilities differ.

[sbddesign]

Understanding that different implementations can and do exist is something that imo is also important to designers. It is more so important for Lightning where multiple implementations are used as whether you choose LND, Eclair or c-lightning for example the product possibilities differ.

I suppose it is a UX concern that needs to be designed for. E.g. how does your UI help the user out in a situation where one lightning node supports Feature X and the other lightning node does not.

[moneyball]

I think we've lost if we force the user to need to comprehend not only Lightning Network as a technology, but also that there are different implementations, and that these implementations have different feature sets, and the user may or may not be able to use features based on which nodes they connect to.

I would also expect to emerge from a period of experimentation and development to one in which core functionality and standards are well established. This might take several years though, so in the interim product designers will need to deal with some of this. For (mainstream) wallets that handle channel management for the user, presumably they'll only connect to peers that support the features needed for the wallet to function.

[pavlenex]

@johnsBeharry and I are working on creating a concept for unified tech primer. We've brainstormed in-person for a few days and are confident that we have a good flow, we'll do a preview soon.

Posting this as a notice so we don't duplicate work.

[Bosch-0]

I think we've lost if we force the user to need to comprehend not only Lightning Network as a technology, but also that there are different implementations, and that these implementations have different feature sets, and the user may or may not be able to use features based on which nodes they connect to.

Yep for sure! Though having these distinct in the guide I do not think results in this. Product designers, the target audience of the guide, should be aware of this.

Any chance of a sneak preview @pavlenex 😆

[pavlenex]

Hopefully in.a few days @Bosch-0 for now it's just a brainstorming doc that I doubt anyone but Johns and I can understand :) Promise we'l have something up in a form of a google doc for an early preview.

[Bosch-0]

Just updating this issue with the WIP: https://docs.google.com/document/d/1BioeJuY_fxF6Ym68VrSyWX5CMTplZzguv32diQE1Kcg/edit#