-
Notifications
You must be signed in to change notification settings - Fork 7
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
add autotls blog post #137
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Marcin Rataj <[email protected]>
Co-authored-by: Marcin Rataj <[email protected]>
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.
Great post! A few nits:
Co-authored-by: Guillaume Michel <[email protected]>
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.
Excited for this to go live. Added a few comments with a lens towards using this for browser advocacy and drawing in new users, and 2 small typos.
src/_blog/aut-tls.md
Outdated
|
||
[Interplanetary Shipyard](https://blog.ipfs.tech/shipyard-hello-world/) is excited to announce [AutoTLS](https://registration.libp2p.direct/), a new service that automates the issuance of Let's Encrypt wildcard TLS certificates for libp2p nodes. | ||
|
||
This is a major leap for the libp2p ecosystem, because it allows connectivity between browsers and libp2p nodes using Secure WebSockets, opening up a new class of use cases for libp2p that were previously cumbersome. |
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.
Would be great to include 2 marketing/advocacy points here:
- Would be great to get more specific about "new class of use cases" so devs who aren't yet libp2p users can more easily identify "oh, that sounds like me", e.g. "making it easier than ever to build peer-to-peer web applications".
- Something about how this is an in-between step while we're also working with groups like Igalia to expand native browser support, which would be even better.
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.
Two obvious and known use case I'm thinking about:
- Direct retrieval, e.g. less reliance on recursive gateways in IPFS land. Another way to frame this: "quicker time to self publishing content on the web"
- Browser based light clients for blockchains. By being able to connect to Ethereum consensus nodes and any other libp2p based blockchain means you can in theory forgo paid/centralized RPC endpoints and build much more decentralised light nodes.
Something about how this is an in-between step while we're also working with groups like Igalia to expand native browser support, which would be even better.
What do you mean by native browser support? As far as I'm aware it's Igalia is working on fixing WebTransport in Chrome and working on custom protocol handlers that could be bound to service workers from extension. I'll add to add something about how WebTransport is much better designed for this since it supports self-signed certificates, less round trips, and avoid double encryption.
- [IPFS Desktop starting with v0.40.0](https://github.com/ipfs/ipfs-desktop/releases/tag/v0.40.0). | ||
- [js-libp2p](https://github.com/libp2p/js-libp2p/tree/main/packages/auto-tls) for Node.js. | ||
- [go-libp2p](https://github.com/libp2p/go-libp2p/tree/master/examples/autotls). | ||
|
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.
Here or else, include who/when it should not be used.
TODO before merging