Conceive user account

[kernelkind]

There should be a conception to represent a user's account to be able to save(#110)/load(#112) to/from disk. This should allow for easy access to multiple accounts in notedeck and android.

I propose:

struct SerializableUserAccount {
    key: nostr_sdk::secp256k1::SecretKey,
    relays: Vec<String>,
    // TODO: variable for bookmarks
}

and

struct UserAccount {
    key: nostr_sdk::Keys,
    pool: RelayPool,
}

Then in app.rs Damus would hold a variable accounts: Vec<UserAccount>. When a column needs to access a user account's pub/priv key or relays, it would access the respective Damus::accounts

[kernelkind]

@jb55 thoughts?

[jb55]

I think @mikedilger has a NIP for an encrypted on-disk format for secret keys. on android we will need to use the keystore API, but we can do that after.

as for bookmarks and relays, we can just use notes in nostrdb for this (relay list, bookmarks list)

[kernelkind]

I think @mikedilger has a NIP for an encrypted on-disk format for secret keys. on android we will need to use the keystore API, but we can do that after.

Would this be nip 49? I saw an implementation in nostr_sdk for it. If we went that route, it seems like we would need to prompt the user to enter a password every time they open the app, which I imagine, could become tiresome. Or we could cache their password, but that would defeat the purpose of encrypting it

[kernelkind]

as for bookmarks and relays, we can just use notes in nostrdb for this (relay list, bookmarks list)

do we have rust bindings for this currently?

[jb55]

On Fri, Apr 12, 2024 at 09:24:43AM GMT, kernelkind wrote:

as for bookmarks and relays, we can just use notes in nostrdb for this (relay list, bookmarks list)

do we have rust bindings for this currently?

yes Damus/notedeck is powered entirely by nostrdb. Every note you see on screen was put there by the nostrdb query engine. The UI only talks to nostrdb, all the network code does is dump data into it.

You can execute a query like so:

let limit = 100;
let txn = Transaction::new(&app.ndb)?;
let filter = nostrdb::Filter::new()
        .authors(vec![our_pk])
        .kinds(vec![42])
        .limit(limit)
        .build();

let results = ndb.query(&txn, vec![filter], limit)?;
for result in results {
    let note = result.note;
    let note_key = result.note_key;
    // ..
}

Subscriptions:

let subid = ndb.subscribe(vec![filter])

// poll for notes:
let new_note_ids = ndb.poll_for_notes(&sub, 100);

---

https://github.com/damus-io/android/issues/111

[kernelkind]

yes Damus/notedeck is powered entirely by nostrdb. Every note you see on screen was put there by the nostrdb query engine.

Yeah I'm definitely aware of this, but I think I see the misunderstanding.

as for bookmarks and relays, we can just use notes in nostrdb for this (relay list, bookmarks list)

You're saying we should create a nip-65 note for the user's relays and a nip-51 note for the user's bookmarks list

[jb55]

On Fri, Apr 12, 2024 at 10:24:30AM GMT, kernelkind wrote:

yes Damus/notedeck is powered entirely by nostrdb. Every note you see on screen was put there by the nostrdb query engine.

Yeah I'm definitely aware of this, but I think I see the misunderstanding.

as for bookmarks and relays, we can just use notes in nostrdb for this (relay list, bookmarks list)

You're saying we should create a nip-65 note for the user's relays and a nip-51 note for the user's bookmarks list

yes nip-65 is the source of truth for a user's relays, same as their bookmark list.

[mikedilger]

I would use the keystore API to store their private key unencrypted so they aren't continually typing their password, but also store a NIP-49 encrypted private key separately as a backup and so people can export the key. I don't think the keystore API lets you exfiltrate keys, does it? So you'll want it elsewhere anyways.

... off the top of my head. I'm just doing a drive-by comment since I was tagged on the issue.