You are reading content from Scuttlebutt
@cryptix %Trhslip+7a8EswzeGnyjZheNmsEMPYzOVVvtK0tqjho=.sha256
Re: %NahlzqB+W

thanks @andre(sphone)! It's always encouraging to hear that it's not just ones one weird thought..

might not be the expert to consult in it, but feel free to toss some questions at me and I can function as a rubberduck for debugging

sure will : ) I understand it quite well, to a point at least since I implemented the wire format in Go. What I'm missing understaning of is the actual handler / dispatcher implementation in JS that does the call invocations, which needs to be changed to support the proposed proxying. Abstractly I already have it in my head, just forwarding by prefix match to the sub-process which is another client-server muxrpc session.

On that note: there is another important TODO wrt plugins2: we need to somehow pass through the actual caller keypair when doing proxying. Currently the shs pubkey is passed along and we need to forward it as well when proxying calls from a remote peer to a plugin. Otherwise the plugin might think that it is doing something for the local ID instead of the remote one.

Join Scuttlebutt now