[SUGGESTION] Full-stack rust-libp2p

[thomaseizinger]

rust-libp2p now has support for the webrtc-direct transport when compiling to WASM, meaning users can now use the same codebase to target a server AND a browser-based client application without having to switch languages.

The initial alpha has been released a couple of days ago. Any objections to posting about this on the libp2p blog?

[marten-seemann]

1. Full-stack is confusing and sounds like overselling.
2. What about webrtc (not direct)?

[thomaseizinger]

1. Full-stack is confusing and sounds like overselling.

Yeah, I wanted it to be catchy but it is meant quite literally. You can use rust-libp2p for your entire stack: frontend and backend. Do you have an alternative suggestion for the title?

2. What about webrtc (not direct)?

We haven't implemented that part yet but I don't think that that has to stop us from writing a blogpost.

[marten-seemann]

1. Full-stack is confusing and sounds like overselling.

Yeah, I wanted it to be catchy but it is meant quite literally. You can use rust-libp2p for your entire stack: frontend and backend. Do you have an alternative suggestion for the title?

Not fundamentally opposed, just concerned about potential confusion with "full-stack (web) development", which usually encompasses backend and frontend.

2. What about webrtc (not direct)?

We haven't implemented that part yet but I don't think that that has to stop us from writing a blogpost.

I think I'd prefer to just have a single "connectivity story completed" blog post. fwiw, that's why we're holding off on a blog post regarding WebRTC support in go-libp2p.

[thomaseizinger]

1. Full-stack is confusing and sounds like overselling.

Yeah, I wanted it to be catchy but it is meant quite literally. You can use rust-libp2p for your entire stack: frontend and backend. Do you have an alternative suggestion for the title?

Not fundamentally opposed, just concerned about potential confusion with "full-stack (web) development", which usually encompasses backend and frontend.

Why do you think that there will be a confusion? It means literally the same thing! The example we have in our repo already hints at how to do this:

• Rust HTTP server to serve a static index.html with minimal JS glue to download and execute a WASM blob
• The same binary is also a rust-libp2p node that listens on a WebRTC transport
• The WASM blob compiled from Rust and uses bindings to talk to the browser's WebRTC APIs

This is full-stack web (+ p2p) development.

2. What about webrtc (not direct)?

We haven't implemented that part yet but I don't think that that has to stop us from writing a blogpost.

I think I'd prefer to just have a single "connectivity story completed" blog post. fwiw, that's why we're holding off on a blog post regarding WebRTC support in go-libp2p.

Single for all implementations or one per implementation? I can definitely see the value of a "connectivity story completed" blogpost but it has a different focus in my opinion. Being able to write a Web + p2p application for the browser and the backend using a single language and library is different from completing the connectivity matrix that allows all implementations to talk to each other.

The latter would also be achieved if we wouldn't invest in WASM at all in rust-libp2p but that is exactly the bit I want to highlight!

I agree that implementing libp2p/rust-libp2p#4389 would make for an even better experience so it might be worth holding off on this blogpost until that is done. @mxinden @DougAnderson444 thoughts?

[DougAnderson444]

I think building software is an iterative process that has no finish line, so we should not wait for a finish line to communicate. If it's also a process that we want to build as a community, I think an important part of that is communicating these iterative successes with the community.

Yes, I think the blog post should be written now. What better way to tell the community where we are, where we're going, and how they can help?

Libp2p and IPFS are big projects with a lot of languages and moving parts. It's hard sometimes to keep up with all the changes as an outsider, newcomer, or community member. The more communication the better, we need to get the word out.

Who knows, the blog post may just be the piece that motivates someone new to help with the effort for the next step.

[mxinden]

• I am in favor of a specific rust-libp2p WebRTC WASM blog post.
• I don't think this post is mutually exclusive to a future "connectivity story completed" blog post, nor do I think we should hold this one or the go-libp2p WebRTC blog post back until the connectivity story is complete.
• I like the "full stack" title. In case you strongly disagree @marten-seemann I am sure we can find an alternative name, e.g. "rust-libp2p in the browser using WASM".

[DougAnderson444]

"Browser to Server and Back, All in rust-libp2p"

[mxinden]

Bumping this in case either @DougAnderson444 or @thomaseizinger is still interested in writing this blog post. I believe it is valuable.

[DougAnderson444]

I've started a draft!