NIPXX - RPC Service Offering

[earonesty]

Suppose i want to build a search engine or ai engine on nostr. First, I index every note I can find, with the origin relay, and the keywords, and a some summary content (prunable).

Then I hang up a shingle "post your search requests to me!"

I accept NIP-59 structured encrypted requests (KIND 10444 Search) I reply with NIP-59 structured encrypted responses (KIND 10445 Search Response) Gift-wrap is a good way of standardizing for any NOSTR RPC.

But what does "hang up a shingle" mean? This is like NIP-28 - chat room. But for services.

Can be a very simple thing:

RPC Service Advertisement

Event Kind: 9121

{
  "id": "<event ID>",
  "pubkey": "<public key>",
  "created_at": <unix timestamp>,
  "kind": 9121,
  "content": "i'm the coolest ai service, send me your JPEG and a number, and i'll send back cool stuff!",
  "tags": [
    ["fee", "21000", "lnurl1dp68gurn8ghj7um5v93kketj9ehx2amn9uh8wetvdskkkmn0wahz7mrww4excup0dajx2mrv92x9xp"],
    ["kind", 1059],
    ["wraps", 2133],
    ["in", "in1", "string field for input 1", "number"],
    ["in", "in2", "number field for input 2", "string"],
    ["out", "out1", "string field for output", "number"],
    ["out", "out2", "array of markdown", "array", "string"],
    ["out", "out3", "object of stuff", "object", "[[\"fd1\", \"out fd 1\", \"string\"], [\"fd2\", \"another fd\", \"number\"]]"],
    ["r", "relay i am listening on"],
    ["r", "relay i am listening on"],
  ],
  "content": "This is an advertisement for an RPC service. It accepts input1 (string) and input2 (number) as input fields. The service will process the inputs and provide the output (string).",
  "sig": "<signature>"

}

Payments sent to the OPTIONAL LNURL MUST contain the RPC request event-id in the metadata.

{
"metadata": [....., ["nostr-rpc", "<event-id>"]]
}

Client events SHOULD be sent as encrypted gift-wrapped events of kind 1059 to the pubkey of the advertiser.

Content of your event should contain JSON formatted as requested:

{
  "in1": "my input....",
  "in2": 334,
}

Content of your response MUST contain JSON formatted as advertised, or be empty.

{
  "out1": "my input....",
  "out2": ["1", "2", "3"],
  "out3": {"fd1": "string", "fd2": 44},
}

Tags on the response MUST contain the event id of the request, and MUST go to the requestor's NIP-65 recommended relays for responses.

[
 ["e": "<event id of the request>"
]

Expiration should be obeyed on both the request and the response.

Responses should also be NIP-59 gift wrapped.

Errors can be sent in a tag with empty content, so there's no ambiguity

{
"content": "",
"tags": [
 ["error", <numeric-code>, "description of error"]
]
}

This will hopefully prevent lots of new NIPs from being needed for all the kinds of services built on NOSTR.

[staab]

Could NIP 89 work for relay recommendations that clients can use, as well as client recommendations that users can use?

[earonesty]

yes, of course, the client should also include a set of relays on the request and the advertisement should have relays as well. but this is not a client reco. it's an RPC service. like an AI or search engine. hopefully, by standardizing on RPC, and supporting gift-wrap we can prevent a plethora of NIP's around custom use cases. It's all just "RPC".

And as to "why on nostr", the answer is "nostr has state, is censorship resistant, and the provider doesn't need to operate a 'server'"