app-specific data wip

[fiatjaf]

@dskvr

[mikedilger]

Would this be a way I could store gossip settings (settings that are unlikely to be sharable with other clients)? I was going to make up a parameterized replaceable event for that, with the parameter being the app name. If not, sorry this is off topic.

[hendore]

I see two sides of the coin here, client data (shared between all users of that client) and user specific client data (not shared between users of the client).

@mikedilger Reserving a single kind from parameterized replaceable events would make sense for these two scenarios, if we can always assume say 30000 is client/app data leaving 30001-39999 for future proposals. Using the d tag we could also namespace different events if an app needs to store several pieces of information that may be updated independently.

// --- User specific client data (only relevant to the user that created the event)

// Fetch a users general settings
{ "kinds": [30000], authors: [USERpubkey], "#d": "gossip/prefs/general" }

// Fetch a users gossip network settings
{ "kinds": [30000], authors: [USERpubkey], "#d": "gossip/prefs/network" }

...

This would be quite nice if clients did publish settings when they change (even if the client stores preferences on the users filesystem). If I switch machine my settings would automatically be synced between every machine I use that client on once those events are received.

Then the other side I think that could be useful would be application data not related to a user, let's say my client has a simple requirement in the form of a featured page where I (as application owner/developer) manually update a list of event ids I would like to promote/feature on the homepage, in this case I think the same event 30000 could be used here, I would just generate a keypair for the client/app and probably wouldn't need to namespace the d tag in this case.

// --- Client/App Data (read by all users of the client)
// This information could be hardcoded in the applications UI but that would require a rebuild/redploy
// if it needs to be updated so storing some app specific data in relays could be nice (for easily updating)

// Fetch the latest featured articles list
{ "kinds": [30000], authors: [CLIENTpubkey], "#d": "featured-articles" }

// Fetch developer contact information
{ "kinds": [30000], authors: [CLIENTpubkey], "#d": "developer-details" }

...

[fiatjaf]

Would this be a way I could store gossip settings

Yes.

[v0l]

Yes please, i want to store snort preferences on nostr instead of in localstorage so it can work across devices

[benthecarman]

Concept ACK, probably simplest way would be to give this it's own custom kind, then store the data in the content and each application can use their own tag.

[fiatjaf]

@benthecarman Yes, that's basically what I had in mind. I didn't finish writing it. Would appreciate if someone could do that for me, otherwise I will do it shortly.

I also wanted to let this open in case some other idea showed up in my mind or on someone else's, but since you had the same basic idea I think we won't go anywhere else.

@hendore's idea of clients themselves having their own keys also works fine with this scheme, we could mention that as a possibility;

[tomasmcm]

For future reference, if anyone wants to get events matching a tag the example by hendore above would be used like this (with nostr-tools):

const events = await relay.list([{
    kinds: [30078],
    authors: [USERpubkey],
    '#d': ['gossip/prefs/general'] // example above was missing these square brackets
}])