--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/design.txt	Sun Sep 11 16:11:37 2022 -0700
@@ -0,0 +1,60 @@
+* First, decide that for some reason the standard pass password manager is
+  unacceptable. One reason may be the risk of compromise or bad commits
+  (by a hostile actor). Another may be matadata leakage: pass stores the
+  name of the (username, password) pair in plaintext.
+  + Regarding the latter, my ccrypt-based solution is better than that, and
+    it immediately struck me as a bad point. Was already thinking about what
+    I would do, and it involved sqlite with all fields except for time stamps
+    encrypted.
+
+* Using sqlite (sqlite3) and one of {Kotlin, Golang, Swift} (in rough order
+  of likelihood) would probably be the way to go.
+* Use a table of the following form to store the passwords (call it passwords):
+  id integer not null primary key
+  name blob
+  username blob
+  password blob
+  notes blob (can be null)
+  created integer
+  modified integer
+  accessed  (read) integer
+  + id will be the low 64 bits of the MD5 hash of the encrypted name
+    case-folded to lowercase (encrypt with a zero IV, don't prepend).
+  + all blobs will be AES-encrypted with prepended IV, a'la EncryptedProperties.
+  + timestamps are seconds or milliseconds since the epoch
+* Use four other tables to store configuration parameters (as needed)
+  integers, reals, strings, blobs.
+  + Each will have an implicit rowid field, a string name field, and a
+    value field of type integer, real, text, or blob as appropriate.
+  + Probably only put those in the schema on an as-needed basis, i.e.
+    a reals table will only exist if we have configuration parameters
+* Four major subcommands: create, read, update, delete.
+  + Error to create a password whose name (case insensitive) already exists.
+  + Error to read, update, or delete one whose name does not exist.
+  + Read should support a --like option to do inexact matching. If one
+    match, act much like read w/o --like. If multiple matches, just list
+    the names.
+  + Read should also support a --clip option that deposits the password
+    into the clipboard without printing it.
+  + Read should also support a --verbose or --long option that causes a
+    stanza-like, key: value dump of the full record. If --clip is used
+    along with --verbose, password prints as "(in clipboard)"
+
+* Use same password everywhere.
+  + Use a dummy config param to ensure correct password (attempt decrypt of
+    it first, write it base64'ed).
+  + Could theoretically use different p/w's for different rows, but causes
+    headaches matching names later, so avoid.
+
+* Misc:
+  + Include a password generator along the lines of genpass.
+    - This should be as a --generate option to the create and update
+      subcommands.
+    - --generate allows four other options: --length, --symbols, --clip,
+      --verbose.
+    - Default length should be 12 (default no symbols).
+    - If --clip supplied, copy new password to clipboard.
+    - If --verbose supplied, print new password.
+    - Default to be silent and not put password in clipboard, just change
+      in database.
+  + Command-line only, no GUI.