I was thinking about writing a simple gRPC service which wraps sn_client functionality. I was thinking of using sn_cli as inspiration for RPC calls and their message payloads.
The goal would be to allow non-rust applications to easily integrate with the safe network, via the sn_client libraries. Then Java, Kotlin, Go, etc, could just talk gRPC and let the sn_client library communicate with sn_node.
While there may be performance gains from building a native (sn_client) library or linking with the sn_client library directly, both would add a degree of complexity. For many apps, gRPC would be sufficient and optimisation could come later if needed.
So, I was wondering if anything like this has already been started/designed? Iām happy to just use sn_cli as inspiration and experiment a bit, but avoiding wheel reinvention would be preferable.
I have a few ideas for wee projects where this gRPCd could be handy. E.g. a safe network based message broker, which could allow different apps/platforms to talk to each other safely and asynchronously, etc.
2 Likes
Poking about for gRPC libraries, this looks pretty straightforward to work with: tonic/examples/helloworld-tutorial.md at master Ā· hyperium/tonic Ā· GitHub
1 Like
I guess the most likely alternative would be using WASM, which I believe will give those languages access to the SN libs but we donāt yet have examples showing that.
@bzeeās recent work may extend that to the browser, but again we canāt see it in action yet.
My approach would be to do it anyway if it interests you, but I also donāt like working on stuff that might be obsolete. Hence my pushing for clarity around APIs, WASM, and the WebSocket build.
2 Likes
Interesting article on the state of WASM as a target: https://www.javaadvent.com/2023/12/a-return-to-webassembly-for-the-java-geek.html (3 months old).
It looks like a lot of progress has been made, but still a lot more to do too.
2 Likes
Another option you might be interested in is wry: Cross-platform WebView rendering library in Rust that supports all major desktop platforms like Windows, macOS, and Linux.
Iāve been looking at options for a Rust based browser example so it can use the Autonomi APIs directly and this is the most promising so far, but I though it might be interesting to you too as it would allow you to build a true client and not need a proxy/gateway.
There are some nice examples in the repo, including two showing how to implement a custom protocol. BTW, any thoughts on what to use instead of āsafe://ā. Iām not really warming to āautoā or āxorā but will probably go with āautoā until something else comes along.
It was really neat to see things loading directly from the network with your gateway app. I wish we knew whether Autonomi have anything planned browserwise because it is so much more powerful as a demo and to show full capabilities. But until we learn anything Iāll probably continue to try and put something very simple together based on wry and a CLI to publish static websites.
Wry looks nice! Iāll take a proper look later. If itās written in rust, it canāt be too tricky to graft in sn_client. It would be great to just get basic requests pulling (DOM could come later).
I agree it has a big impact on users too. Even the sn_httpd proxy lit up some imaginations. If we had a proper, basic, browser that just worked natively, minds would be blown! Imo, that final, small, step can have the biggest impact - the backend is awesome, complex, amazing etc, but users want to experience something visual.
I did have a poke around in Servo btw, but the CSS rendering didnāt look good out of the box. I was hoping it was in good shape and written in rust.
Great question! Do we even need a protocol at all, I wonder? Will it all just be autonomi client requests anyway?
Given NRS will surely come, xor may be counter productive.
Maybe safest to use something for now, but certainly modern browsers donāt need them. We could just internally use something to make the URL well formed, but perhaps it doesnāt need exposing.
Take a look at this conversation with the Tauri folks. I was asking about using wry and tao for a browser demo.
Turns out Tauri = tao + wry 
so Iām planning to start with a Tauri app and go from there.
Even getting the basic pieces in place is probably going to take a while though.
Ha! I geddit now! 
Sounds great! I wouldnt be surprised if you could get it returning data pretty quickly for simple requests. Iām looking forward to seeing it!
I was taking a look at building a rust service on android last night too. Iāve not messed with that before, but it looks possible. If it works, creating a wrapper around sn_client should be possible too (assuming dependencies build).
That could pave the way for java/kotlin android apps to connect to the network. Permissions will need to be considered at some point, but it would be cool to showcase it. Even running sn_httpd as a service could give a basic taste on android.
Definitely some fun stuff to play with! 
1 Like
BTW Tauri v2 (in recent beta I think) supports Android as well as Mac, Windows and Linux. So four platforms in one app.
1 Like
What do you think about āatnmiā? Itās the same length as https.
My browser demo app is called awe (based on āAutonomi WEbā) so I have.
Not yet implemented:
awe:// for NRS named versioned websites (and other services).
Implemented, in testing:
awx:// for versioned websites by xor address (of register).amx:// for website metadata by xor address.xor://<XOR-ADDRESS> for a file by xor address
I gave up trying to base it on āautonomiā because nothing I came up with was meaningful, aesthetic and easy to type. So I have used āAutonomi WEbā and created things related to that. But obviously its not my decision alone!
EDIT: this is bound to need its own topic!