-
Notifications
You must be signed in to change notification settings - Fork 44
Adds new architecture diagram and update copy #152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds new architecture diagram and update copy #152
Conversation
✅ Deploy Preview for lightningdevkit ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
docs/overview/architecture.md
Outdated
## LDK Architecture | ||
 | ||
## Architecture | ||
 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Diagram:
- doubt: what is wallet tooling ?
- instead of direct arrow to database, it should be to Storage Module(dotted) and then to database.
- "LDK creates events that users can respond to" -> "LDK emits events that users can act upon"
- "Net I/O" -> "Network I/O"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not 100% sure what we mean by tooling, I think it can refer to different types of integrations, HWI, remote signing, encryption, testing in different environments etc.
instead of direct arrow to database, it should be to Storage Module(dotted) and then to database.
We don't really have a Storage Module AFAIK, rather LDK provides the raw bytes for the network graph, channel state etc and the user defines the schema they want to use to back that data up. Correct me if I'm wrong @jkczyz @arik-so
The other changes to the diagram seem reasonable, thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of direct arrow to database, it should be to Storage Module(dotted) and then to database.
We don't really have a Storage Module AFAIK, rather LDK provides the raw bytes for the network graph, channel state etc and the user defines the schema they want to use to back that data up. Correct me if I'm wrong @jkczyz @arik-so
The other changes to the diagram seem reasonable, thanks.
Arguably, there could be a "Persistence" box that sits between LDK and "Data storage" just as "Chain Interactions" sits between LDK and the depiction of "Bitcoin Network". The diagram was meant to be a bit more high-level, thus the use of depictions rather than simple boxes in places. And the term "module" is a bit nebulous. e.g., Is fee estimation a module? It's mentioned in a later slide but isn't depicted anywhere.
Similarly, when making payments someone can bring their own channel scoring or router -- though we provide our own -- but those aren't depicted anywhere. At a higher-level, these are part of making payments. Perhaps there should have been a depiction of (and/or box for?) this in the diagram.
So maybe a dotted box is really either a module or set of related modules. @arik-so Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think that's fair, maybe these dotted boxes are better being termed as components
as you had before. It's tricky some have default implementations others do not. I like the higher-level approach though as it's easier to drill down from there e.g I know to get started I'll need:
- A
PeerManager
- A
ChannelManager
- A way to route payments, generate invoices etc
Then I can drill down into what "modules" are needed to create these objects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So maybe a dotted box is really either a module or set of related modules.
If my memory is correct from when we built this family of diagrams at BTC++, the dotted line was meant to indicate that the developer could swap this out with whatever they wanted. For example, Net I/O could be the pre-built Tokio example, or they could swap that out with their own network I/O stuff. I'm not sure if it makes sense to make that distinction explicit with a key/legend, but I think that was the intent. Many of the other diagrams don't have as many dotted line boxes.
Here is an updated SVG with revised text and a Persistence box.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we remove the arrow from the dotted line going form LDK to Persistence for consistency with the other dotted lines connected to LDK?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, I think so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sbddesign one last nit 🚧
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes it environment agnostic, allowing you to choose your own networking stack, data storage, wallet and blockchain monitoring. In the diagram above the boxes with dotted borders are LDK's modules — these must be configured with either off-the-shelf or custom implementations that you provide. | ||
|
||
We also use an event driven archictecture that will ansychronously prompt you to do an number of things. For example LDK will generate an event when a payment is received (`PaymentReceived`). More on this in a later section. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ignore if i am preempting your next step.
It could be helpful if we add a small subsection with 2-liner about each of the modules and their functionality
(Can tackle in next PR)
2-liner should probably be an answer to:
- Storage: what does LDK use this for ?
- Broadcast transactions: what does LDK use this for ?
etc.
Need not be too detailed in overview section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah the plan is to provide examples for both of these in the following PR's.
I plan to tackle Peer management, Channel management, Payments & Routing and their dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was going to be my feedback after seeing the preview...I liked the organization of Peer management, Channel management, and Payments & Routing from the btc++ prezo.
docs/overview/architecture.md
Outdated
|
||
::: tip Langauge Bindings | ||
|
||
Although the core SDK is written in Rust, we support a number of other programming langauges. These include C/C++, Java, Kotlin, Swift, JavaScript/Typescript/WASM (Alpha). Check out [examples](../examples.md) to see some of the implementions out in the wild! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Synced on ldk-dev group regarding the same, also about readiness of bindings.
"Java/Kotlin, Swift, TypeScript/JavaScript(Beta), C++(Alpha)"
We don't want to list C, because its unusable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ConorOkus Will need the new diagram in the branch before merging. |
docs/overview/architecture.md
Outdated
|
||
::: tip Langauge Bindings | ||
|
||
Although the core SDK is written in Rust, we support many other programming languages. These include Java/Kotlin, Swift, JavaScript/Typescript/WASM (Beta), C++ (Alpha). Check out [examples](../examples.md) to see some of the implementations out in the wild! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should also drop WASM from the list
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably "TypeScript" instead of "Typescript" while you're at it lol
Thanks @jkczyz @G8XSU @sbddesign. Could do with one more look-through before I squash. |
64e5da6
to
65bd98f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Feel free to squash.
## LDK Architecture | ||
 | ||
## Architecture | ||
 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
earlier this picture was .png in previous revision, its back to .svg i guess.
svg are generally not considered standard and are security concern because they are executing code.
"The danger of an SVG file comes from the fact that it’s an XML that can have embedded CSS and JavaScript. The web browser will automatically run any JavaScript embedded in an SVG file. Therefore, if the script contains malicious code, it will place the user’s computer at risk."
from: https://blog.online-convert.com/svg-file-and-its-danger/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although we created this image and its not a security concern, but would prefer if its just png or jpeg for simplicity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a slight issue with the dashed strokes in that image, so I fixed and optimized it. See above 73kb SVG.
Although we created this image and its not a security concern, but would prefer if its just png or jpeg for simplicity.
While there is certainly the possibility that malicious code can be hidden inside an SVG file, the same can be said for any other pieces of code on the site.
Also, the existing architecture page contains 20 SVG tags in its current form. Including the current architecture image.
Therefore, I don't buy that argument at all @G8XSU.
Now having said that, if we want to have a discussion about switching to PNG or JPG for images like these, that conversation should be focused on usability and load time, IMO.
I ran this through a PNG optimizer and got it down to around 35kb. And we can get similarly good results with a 2x export of the same image.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly agree with @sbddesign here. Even if we want to have the performance discussion a 73kb optimized SVG is pretty good for this example and usage. I'll update to use the latest SVG provided for now and log an issue to discuss the overall strategy for image formats etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well i was just pointing out that in previous rev it was png and now it changed to svg.
As long as it is intentional and not a miss, go ahead since we are uploading these to server 👍
09a8083
to
9c2eabc
Compare
Screenshots & Preview

