Wip/methods

[josephmturner]

I'll keep pushing to this branch, but I figured I'd submit the PR since I have questions:

The options argument to drive.mirror has a properties key whose value is currently specified in methods.json as an empty object:

"options": {
  "type": "object",
  "properties": {}
}

Should we specify the types of those options?

What about the whose value are functions? Just "function" or do we want to specify a function signature?

filter: (key) => true,
metadataEquals: (srcMetadata, dstMetadata) => { ... }

Should we differentiate required and optional arguments?

Should the type of buffers be string?

[RangerMauve]

This is a great start ty.

Should we specify the types of those options?

Maybe? We only need to prioritize whatever ones will be used by hyperdrive.el IMO

What about the whose value are functions? Just "function" or do we want to specify a function signature?

Sadly I think we'll need to omit those and revisit the issue if we end up needing them. No easy equivalent of passing a function over json rpc

Should we differentiate required and optional arguments?

Yeah if you can, mark any required properties with required as per this example

Should the type of buffers be string?

Yes, and maybe we can add another field like format: "base64". We can use that as a cue on the back end to parse the data out when assembling the params

[josephmturner]

Should we specify the types of those options?

Maybe? We only need to prioritize whatever ones will be used by hyperdrive.el IMO

Ok!

What about the whose value are functions? Just "function" or do we want to specify a function signature?

Sadly I think we'll need to omit those and revisit the issue if we end up needing them. No easy equivalent of passing a function over json rpc

That makes sense. I found this, but it seems pretty hacky.

Should we differentiate required and optional arguments?

Yeah if you can, mark any required properties with required as per this example

Like this?

Should the type of buffers be string?

Yes, and maybe we can add another field like format: "base64". We can use that as a cue on the back end to parse the data out when assembling the params

Like this?

[josephmturner]

Add a "returns" property to each method.

[josephmturner]

objects, arrays, base64 strings

[josephmturner]

I'm adding a "format": "base32" for topics, since according to the docs, they need to be 32-byte buffers.