`rclient account --new`, `rclient sign`, alicePaysBob, ethSig, loader, locker

[dckc]

What do you think about syncing with where I'm at? Is it cost-effective to break these into smaller PRs?

• cli with docopt
  • register modules
  • make accounts
  • sign data
• previewPrivateNames
• RHOCore.toJSData: accept map as well as sends
• unstructured phloLimit, phloPrice
• alicePaysBob
• proxy
• ethSig
• loader
• locker

[JoshOrndorff]

Technical Thoughts

RChain-API should probably have some kind of mission statement or something to avoid scope creep. Although we never discussed it. I always thought of it as something like:

RChain-API is a js library that makes it easy and convenient for js devs to interact with the RChain Coop's RNode client, and the dApps that it runs.

So I imagined that RChain-API wouldn't have an entry point (except for testing or maybe an example). According to that vision, here's what I think about the various things you suggested bringing in.

• cli with docopt -- Make it a separate project that depends on RChain-API
• previewPrivateNames -- Definitely. That's a grpc service that js devs will want.
• RHOCore.toJSData: accept map as well as sends -- Definitely
• unstructured phloLimit, phloPrice -- Definitely. That's just node8 compatibility
• alicePaysBob -- Is this a demo / test? Is it a function a js dev might call related to her own dApp? I'm not sufficiently clear how reusable this is to assess whether it belongs in the library.
• proxy -- Definitely. That's super useful and similar to truffle's contract abstractions.
• ethSig -- The RLP stuff? -- Isn't it mostly rholang code? Is it better suited for librho or something?
• loader -- Make it a separate project (ps https://github.com/JoshOrndorff/rhopm/issues/2)
• locker -- Not specific to js devs. Put it in librho?

Personal Thoughts

As you know I'm trying to distance myself from the coop, but still very excited about rholang and process calculi for the blockchain in general. So @dckc, you're basically the primary maintainer on this project now. So if you want to take it in a different direction than my proposed mission statement, that's totally up to you, and I'll still be as supportive as I can.

[dckc]

We did discuss scope a bit... it's just that we're doing sufficiently well on the "easy and convenient" part that using this as a playground is much easier than making new projects. :)

I'll see what I can do about at least organizing rclient, loader, ethsig as examples which could be moved to separate projects straightforwardly.

[dckc]

Nonce management doesn't seem complicated to me. It's about 10 lines of code, no?

[dckc]

My understanding is that a nonce is necessary for digital signatures to provide adequate security.

I would need to see a compelling argument to the contrary.

[odeac]

how do you manage nonces in presence of parallelism?

If you have two processes working with the locker how do you make sure that both work with a valid nonce?

[dckc]

The down-side of a nonce that I see is performance / scalability: it serializes what would otherwise be concurrent work.

[dckc]

Ah.. so the complication you refer to is in the callers. Yes, that is a challenge.

[odeac]

My proposal relies on the uniqueness of the return channel and the uniqueness of the proxy channel, both being Rholang unforgeable names.

This way the return channel acts as a nonce so we are protected from a replay attack.

Also, the returned poxy acts as a session key i.e. when it gets out of scope the item stored in the locker is no longer accessible.

[JoshOrndorff]

In my conversation with @odeac in rchain-dev#cryptography, we decided that once https://rchain.atlassian.net/browse/RCHAIN-1048 is fixed, the unforgeable name will be session-specific and can serve the role that a nonce is currently serving.

[dckc]

Is the full argument that unforgeable names subsume serial nonces available somewhere?

(What's "session-specific"?)

[dckc]

@odeac with the getSeedProxy design, am I limited to sending unary messages to the seed? How would I send a typical message such as seed!("voteFor", "Lincoln", *reject, *resolve)?

[dckc]

The unary limitation is one aspect of an issue I've been asking about since June: a uniform calling convention for rholang.

https://forum.rchain.coop/developer/rholang/ocap-happy-method-dispatch-idioms-in-rholang/#post-252

Monte has a uniform calling interface, which means that any message can be sent to any object, and rejection is always done inside the object’s message-receiving code at runtime. -- monte docs

Monte inherits its uniform calling interface from E, but I'm not sure where that aspect of E was originally documented.

[dckc]

Do we have spread syntax? i.e. for (...msg <- proxy) { seed ! (...msg)}

[dckc]

return ! (proxy) should be return ! (bundle+{proxy}), yes?

[dckc]

@odeac would you please re-open RCHAIN-1048?