Re: Nostrscript/Nostr Extensions spec and ABI

On Mon, Jul 10, 2023 at 01:04:14PM +0200, Melvin Carvalho wrote:
>po 10. 7. 2023 v 9:28 odesílatel Semisol <hi@semisol.dev> napsal:
>
>> Starting this thread so that the ABI and other details for
>> Nostrscript/Nostr Extensions can be discussed. Here’s my thoughts:
>>
>> # Naming
>> “Nostr Extensions” is probably better than “Nostrscript” since it
>> represents what this actually does (extends a client), and the name
>> Nostrscript could be confusing since it could be interpreted as a
>> programming language.
>>
>> # Goals
>> - Allow for easily extending Nostr clients.
>> - Compatibility: Extensions should work on any platform: the web, mobile,
>> desktop, etc.
>> - Modularity: Not every feature has to be implemented by a client or
>> extension.
>> - Extensibility: It should be easy to add new capabilities for extensions,
>> such as custom feeds
>>
>> I’ll post my draft ABI later once I fully polish it.
>>
>
>Hi Semisol, thanks for sharing
>
>For those less familiar with nostrscript (or nostr!), there's some search
>results here:
>
>https://primal.net/search/nostrscript
>https://nostr.band/?q=%23nostrscript
>
>Aside: Primal also searches the fediverse, and is in general a pretty
>decent search experience (for news etc)
>
>From one of Will's original posts:
>
>web → javascript → 🌎🚀🌑
>nostr → nostrscript → 🤔💭❓

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

Received on Monday, 10 July 2023 15:15:34 UTC