ssbc / muxrpc

lightweight multiplexed rpc

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

The sync-type of rpc method can be problematic when building for both the local and remote APIs

pfrazee opened this issue · comments

See https://github.com/ssbc/patchwork-threads/blob/master/index.js#L368:

// decrypt
var decrypted = ssb.private.unbox(msg.value.content, next)

// HACK `ssb` may be a local reference to scuttlebot, or an RPC instance
// if it's a local reference then the call signature will be sync
// the easiest way to tell if that's the case is if the `.hook` method is present
// this is pretty brittle - Im opening an issue for a better solution, but this is a blocker
// -prf
if (ssb.private.unbox.hook)
  next(null, decrypted)

function next (err, decrypted) {
  if (decrypted)
    msg.value.content = decrypted
  cb2()
}

It'd be good if there was a simpler way to standardize this. Maybe we should just update the unbox() implementation to optionally take a cb?

optionially take a cb is acceptable, but probably better if all sync methods can behave like that.
another alternative would be a way to introspect the api and check if something is sync, async, source, or sink?

I think it'd be best if all sync methods behaved that way. Maybe secret-stack could wrap its sync functions?

yeah, probably could apply something like that when it adds the hooks to them.