- From: William Casarin <jb55@jb55.com>
- Date: Mon, 10 Jul 2023 08:24:40 -0700
- To: Semisol <hi@semisol.dev>
- Cc: public-nostr@w3.org
On Mon, Jul 10, 2023 at 06:19:34PM +0300, Semisol wrote:
>
>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
Can you link or ideally mail it as a patch(set) for review? Then I would
be able to respond inline here to comment on it.
Received on Monday, 10 July 2023 15:24:47 UTC