standardize config storage on disk

[fiatjaf]

Currently https://github.com/fiatjaf/noscl has the following config file:

fiatjaf@hazlitt ~> cat ~/.config/nostr/config.json
{
  "relays": {
    "wss://relayer.fiatjaf.com": {
      "read": true,
      "write": true
    }
  },
  "following": null,
  "privatekey": "90f64bae57bac94077e181ee92efa4636873d14858b5adf9600f712cb6c1d58c"
}

We could agree on some standard format so multiple installed applications could reuse the same data without asking the user to set up keys and relays and followers lists again and again.

I know storing private keys in plaintext is not very good, so we could probably have a field for plaintext and another for keys encrypted with a password and each app uses the one it prefers or the one which is available.

[futurepaul]

hm unless someone wants to use different apps for different purposes / with different private key.

also if the scheme isn't specified formally I could see different apps clashing and overwriting each other. (like right now we don't have a "following" field, and if we serialized our app state naively we'd wipe that part of an existing config)

maybe loquaz could offer to import a /nostr/config.json if it sees one, but then store its own state in ~/.config/loquaz/config.json so we don't have to stress about it?

[fiatjaf]

We wouldn't stress, but all the users would, by having to manage multiple different files.

I like to think there will be half a dozen different nostr-powered apps in people's computers in the not distant future. I like to think that is more desirable than a single super app -- or that most apps will be inside a browser, for example.

What I'm proposing is that we specify the scheme formally! We do it now, stress a little about it, and users are happier later!

If you're worried about people overwriting things that would only happen if an app developer is very careless, in that case we shouldn't use their app anyway, right? A very careless app developer could even write software that will take your keys and steal all your money, but we need other defenses for these things already.

Maybe I'm being too naïve. Am I?

[emeceve]

This can be formally specified as a NIP and is up to the client give support to it or not. Clients can use this scheme directly or offer a way to import/export to the specified scheme.

[fiatjaf]

My question now is: what if someone writes an extra field that isn't specified? I think other clients should not erase that field.

How hard is it to support this on Rust? Typed languages are often not great with JSON documents they don't understand fully.

[fiatjaf]

https://github.com/fiatjaf/nostr/issues/54

[futurepaul]

I agree that "if an app developer is very careless, in that case we shouldn't use their app anyway, right" but at that point that careless app dev has already corrupted my app's db, giving my user a bad experience even if I'm not the careless app dev

it's a bit more work to make sure the extra field isn't wiped (that's what I was referring to before) but should be possible maybe we use something like this: https://lib.rs/crates/json_dotpath

[fiatjaf]

What about having a file for the key, another for the relays and so on? This way they're clearly separated and it's much harder for a careless developer to do bad things.