nip/data-functions

[samthomson]

WIP - conversation/feedback welcome, but it's not review ready yet.

This NIP proposes associating data with code, so that complex data can be recomputed on the fly using DVMs.
Similar to attestation types (npi 85?) where someone crunches data and we just query the output, with this NIP we ask for the crunched data, but provide a serverless function to run in order to populate it if it wasn't already defined (ie cached).

A simple example would be comment/reaction counts, or the reactions/comments themselves. Or more complex would be taking a lots of data (eg several weeks of historical weather data nip-whatever) and doing some aggregations on it.

The goal here is to let clients have snappy experiences while working with derived (not root query) data while:

• reducing complexity in the client
• keeping relays dumb (data in data out)
• client builders don't need to invest heavily in infra (or devs to make custom caching stacks)
• users don't lose centralisation by leaning on non-nostr native caching stacks
• caching itself is outsourced to network effects; kind 1337s are democratised, and a secondary caching layer can emerge separate from the underlying datas

I've started a rough implementation in relaykit:

A client can then consume as follows:

Here's a comparison showing first load, of me fetching weather data from the last month and calculating an average temperature versus me asking for the same one event of the same derived data:

And here's a second load, ie how it would be for a second visitor to the same client.

Note, if the DVM isn't locked down with a whitelist, then a client can publish a request to the dvm with an ephemeral key to avoid forcing users to login, so this is also a 'guest' friendly solution.

[fiatjaf]

Aren't clients already doing this for many things, like your comment/reaction count example?

[samthomson]

The approach here uses serverless functions (nostrfied in dvms) to make a flexible caching layer any client can build with. I’ve seen clients with custom caching layers, and in best cases nip85 attestations (so at least the data goes back to the data), but not like this. Can you share more? 🙏

…

-------- Original Message --------

On Wednesday, 06/03/26 at 15:47 fiatjaf ***@***.***> wrote: fiatjaf left a comment [(nostr-protocol/nips#2367)](#2367 (comment)) Aren't clients already doing this for many things, like your comment/reaction count example? — Reply to this email directly, [view it on GitHub](#2367?email_source=notifications&email_token=ABSIPNFPCY5WGRUNFLOK4AD46AT6TA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRRGMYDAMZYGQ32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4613003847), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABSIPNBUFME2P5HNYV3M54T46AT6TAVCNFSM6AAAAACZYYIWJCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DMMJTGAYDGOBUG4). You are receiving this because you authored the thread.Message ID: ***@***.***>

[fiatjaf]

Is the idea here to publish some custom map/reduce JavaScript code and then some DVM will execute that code and publish the results as events?

[samthomson]

@fiatjaf yes/no. It's not prescriptive. I use a 1337 code sample kind for the serverless function, but then define a replaceable 31337 which references a 1337 but also adds config (ttl, dvm relay, read relays, write relays, optional params for the serverless function). It could be used for anything. Reaction/comment counts (or reactions/comments themselves) could be populated, but also anything. for instance above in my example I get tonnes of - nostr - weather data and crunch it.