Re: Nostrscript/Nostr Extensions spec and ABI

On 10.07.2023 18:15, William Casarin wrote:
> On Mon, Jul 10, 2023 at 01:04:14PM +0200, Melvin Carvalho wrote:
>> snip
>
> I like the name nostrscript for the branding, even if it is not
> technically a script, right now in damus it's synonymous with
> AssemblyScript + a custom nostr lib that communicates with damus.
>
> I expose a few functions that scripts can call into the host:
>
> ```
> enum Command {
>     POOL_SEND = 1,
>     ADD_RELAY = 2,
>     EVENT_AWAIT = 3,
>     EVENT_GET_TYPE = 4,
>     EVENT_GET_NOTE = 5,
>     NOTE_GET_KIND = 6,
>     NOTE_GET_CONTENT = 7,
>     NOTE_GET_CONTENT_LENGTH = 8,
> }
>
> declare function nostr_log(log: string): void;
> declare function nostr_cmd(cmd: i32, val: i32, len: i32): i32;
> declare function nostr_pool_send_to(req: string, req_len: i32, to: 
> string, to_len: i32): void;
> declare function nostr_set_bool(key: string, key_len: i32, val: i32): 
> i32;
> ```
>
> I've been thinking about changing this entire interface to just:
>
> ```
> declare function nostr_cmd(json: i32, json_len: i32): i32;
> ```
>
> where commands are serialized using json. This wouldn't be the best for
> performance but would be nice for flexibility and avoiding the pain of
> ABI between wasm hosts and guests.
>
> Another alternative is something like what I have now:
>
> ```
> declare function nostr_cmd(cmd: i32, val: i32, len: i32): i32;
> ```
>
> Which provides a simple interface for sending a command (enum i32), a
> string and the string length. This works well for many types of commands
> but not all, which is why I have one-off functions for things that don't
> fit that model.
>
> I think reducing the surface area of the calls is a good thing for
> implementation ease and future extensibility.
>
> I haven't spent too much time thinking about this, it's just what I have
> at the moment. Curious to see what others come up with.
>
> Cheers,
> Will

My ABI exposes one import per command (I recommend you read it if you 
did not yet), which has some advantages, compared to a single interface:

  * You can know what a module can do beforehand, and modules that use
    unsupported features will never be able to load, which helps
    simplify development
  * You still get to retain the typing on arguments