When working towards File Orbits beta, I got bit on accidentally reinstalling on my windows machine and suddenly my mesh exchange stopped working.
It hit me...how does the invite mechanism exchange the private key?
I manually setup my two machines with the mesh zip file. When you install the application it sets up the identity. When I started the "walking skeleton" to prove this idea, it was much more bare bones hehe. On install it generates a identity for the IPFS node and the swarm private key. If you have the identity which is public you need the private key to get access. Even if you have access you still need a JWT from the user session from the personal data server. This is how I was able to secure following the defense in depth principle.
Well that's all well and good, it worked! Now fast forward after some changes where I wanted to automate the invite process to be more user friendly without a zip download and upload. The invite is simple use an AppView endpoint that holds the invited users with lexicons for it.
I was still relying on my previous zip uploaded process so it looked okay at first. That's when I reinstalled manually and boom new swarm key and identity...so my mesh stopped talking to each other and my MacBook had no idea what files I was uploading.
I was like, simple! I will just make it assume the identity not thinking about the swarm key. So I did that...then it hit me. Its time to solve the exchange of the private swarm key.
My good friend and colleague was urging me to checkout libsignal since they support e2e encryption. A couple challenges arose with that. It implies the signal identity. It would not be WASM compatible in the future. I would also be tied to an ecosystem that is not a part of AT Proto/Rust Crypto dependencies it in-directs those. Which normally indirection would be great but only for dependency injection not the core technologies.
So fast forward after days of rate limits hit on my personal Bluesky account, and uninstalling and reinstalling so I can use my fileorbit account. Welp another hurdle and I hit the first hurdle and now a second without clearing either uncovered another issue. I don't support multi users/multi-mesh.
I wrote my architectural vision via DiD scoped private swam keys that would not expose the cloud private swarm key. It hit me...why don't I solve this in the same way!
I can leverage a list of DiD's and their swarm keys persisted encrypted at rest and when a user requests something from the network I can use the WebSocket exchange to tell my swarm/gateway who I am via OAuth. Allowing me to then provision the right secret. Allowing a single libp2p instance to multiplex many connections. Creating the secured mesh I was looking for!
Well now I have three problems I need to generalize the P2P network to not look at is this a cloud hosted "safety net" node and allow all nodes to participate as equals. This is great since I intended this but was not sure how could I get around the protocol limits of libp2p. I can't host a instance per user, I would go bankrupt or fail to scale. I can however in my network behavior extension enable swapping secrets via an authenticated source. Giving me what I have been searching for. Authenticated IPFS by combining Authenticated Protocol with Inter-Planetary File System.
To speed up my development loop and because waiting two hours for a cloud deployment is not acceptable, I moved towards better integration tests that simulate the PDS join mesh request.
Once my integration tests were in place I moved to extracting the mesh join into its own service on the servers OS so I have a modular monolith. This allows me to scale in the future as micro-services but for now be cost conscious. More importantly it allowed me to hotswap both the local install and cloud installs in a 15 minute feedback loop as opposed to the 2hr time I had to wait for my pipeline to build my large rust application and then deploy and build the linux distro.
After many iterations I got the Cloud Mesh Join feature working. Its a little clunky for now but the installer after it sets up the app. It prompts you to join the cloud and opens a tab to the site which initiates it from the cloud the same way a self hosted peer would. Your friend or even your own node would invite you and then you accept and finally you'd say join mesh and it would exchange encryption keys via the PDS as a proxy. That workflow I have yet to work through am just happy that the cloud place can connect to my local place on my desktop. Allowing the alpha phase to move to accepting customers more than just self-hosting model.
Necessity is a the greatest inventor, what started as a manual zip file exchange, now is a multi-mesh network solution and a seamless mesh join process that does not require a zip file to be sneaker-net through to each setup. Login, click through some screens and boom you're connected.
Until next time peace nerds and normies!
~ Triforce
P.S. While writing this rant I got off track and spun it off into another post about my CI/CD pipeline challenges the Tangled.org team helped guide me on.
Check it out - Murphys Law in Full Effect!