That NIP looks good, would implement.

Do you know if many relays support https://github.com/nostr-protocol/nips/blob/master/33.md? I think it would directly enable the key-value storage feature on Nostr that I've been pushing. D tag is the key.

K-V storage would actually enable you to set block / follow / like status per event or user (d: "likes/${eventId}", content: "true") so you don't need to worry about your devices being out of sync and overwriting each others' lists.

And the events stay smaller when you update just one key, vs. events that contain a list of potentially 1000s of entries.

But that's something we can do later. NIP42 looks good.

Reply to this note

Please Login to reply.

Discussion

Other benefits of k-v storage:

- build all kinds of applications on top of nostr without having to specify new event kinds (online store, uber, games)

- toggling a value of e.g. like, boost or follow back and forth doesn't create a trail of events and delete events

Actually it doesn't even matter if relays support it or not. But they can save space by supporting it.

With K-V storage, directory listing filters like { "#d": ['store/items*'], authors: [...] } would be useful. That query would list store items for all selected authors (your friends-of-friends for example, in which case bloom filter could be used to make the request smaller).

from this discussion it looks like #[3] implemented it on his nostream relay already

https://github.com/nostr-protocol/nips/pull/54

the key-value storage thing is very interesting. and I have to agree that having likes as a replaceable event does make a lot of sense.

give it a try, let me know if you find any issues. it should be live on wss://nostr-relay.wlvs.space ;)

thanks!!