addUnboxer is not a function

[christianbundy]

It looks like we aren't exposing the addUnboxer() method over MuxRPC. Should we be? I was thinking yes, but I don't think we can pass functions over MuxRPC unless we're stringifying them. I haven't done any testing, so I could be way off, but my guess is that we have three options:

• Decide that addUnboxer() doesn't work over MuxRPC and it never will, which sucks.
• Convert from string to function, which gives us [authenticated] arbitrary code execution but doesn't work with require() or anything since modules on the clients probably aren't available on the server. Unless we compile into one big payload? Native modules would throw a wrench in this.
• Add the capability for a remote unboxer, so the server hits up the client to do the unboxing (!) which is probably slow but is at least correct.

Anyone have a feel for the right move here? FWIW this is me trying to add SSB-Identities to Oasis.

cc: @staltz @mixmix @dominictarr @arj03

[mixmix]

I don't think addUnboxer remotely is a good idea at all, because :

• we don't know when it was added ... which means we would need to rebuild?
• sending functions over as strings seems like a terrible security problem

Can we talk about ssb-identities and what you're trying to do? AFAIK that code is beta.. as in has seen some use but not been stress tested

[christianbundy]

Hi! I was trying to use client-side plugins over MuxRPC, so I'd be loading SSB-Identities in the client rather than in the server. The problem is that adding an identities requires adding an unboxer, which I can't do remotely over MuxRPC. This basically means that any 'lessbot' has to be both a database and an identity management service, you can't do identity management on the client-side.

This is still a problem, but I'm planning to drop most of the existing Secret-Stack/MuxRPC infrastructure (including SSB-Identities) so I think this is fine to close.