Oddbean new post about | logout
▲ ▼
semisol | 11 days ago (raw) | root | parent | reply | flag +1 
 I see several minor issues:
- why encode nsecs as bech32 and not hex?
- bunker npubs should be limited as much as possible (1 key = 1 npub or 1 key per bunker) as it adds additional filtering costs to relays, and therefore be independent from users
- secrets only need to be kept for pairing and should most likely be separate from users
and some other issues
▲ ▼
semisol | 11 days ago (raw) | root | parent | reply | flag 
 I guess the best way to redesign would be to have a set of keys (with their bunker nsecs), a set of users, secrets for pairing, and already authorized connections (possibly with descriptive names)
▲ ▼
Alex Gleason 🐍 | 11 days ago (raw) | root | parent | reply | flag 
 - bech32 is used for unambiguity, and an open door to putting ncryptsec in there.
- each new authorization (eg `bunker uri` call) creates a new keypair for security reasons. However you can reuse the same bunker URI "n" number of times by passing an `-n 3` flag for "3 usages", for example. I decided this is actually the behavior I want. So I can say "hey social media manager, can you manage this account?" and then send one URI for all their devices instead of a separate URI for each of their devices.
- in this design, the secret is a uuid, and although it's only used "n" times (1 by default), it's still stored as an ID of the connection, so `knox revoke <secret>` can revoke it.