-
Notifications
You must be signed in to change notification settings - Fork 43
Roadmap
Versioning should be straight forward. The minor numbers should increment as needed to indicate new minor features, while the major numbers should increment as needed to indicate new major features. There is no upper limit on the minor number. Additional nested minor numbers might be appropriate for bug fixes.
Only meant for core functionality and basic set of features. Things like encryption/decryption on-disk format, an external API, modular theme support, etc.
Core release. The on-disk encryption format is standardized, which is AES-256 in CTR with HMAC-SHA512 on ZLIB-compressed data. For the foreseeable future, this will not change, to allow old notes to remain decryptable. If the need to switch to a new encryption mode changes, such as AES-256 in GCM mode, some sort of migration tool or functionality will be built into the application, allowing decryption of the old notes.
Introduce an external API. Discussion about whether or not a Hashcash token should be applied to the POST when using the external API should be started. Using the API through the command line with a Hashcash token would require a bit of work on the part of the user. Using a dedicated application that uses the API would not.
Themes, themes, themes. A mobile theme should be introduced for mobile clients, such as smartphones and tablets, making it easier to navigate the web interface. Further, companies should be able to skin the d-note app as they see fit for their own over branding, look and feel.
Possibly thinking that account support would be the next major feature here. Having the ability to login with your own account, create a note, and send it. Through your account, you could see if your note has been read or not. An account could also introduce address book support, allowing you to import an address book, or hook into an external one, such as CardDAV, and use those contacts to send your notes to. Accounts should never be mandatory.
Possibly the ability to view the note multiple times, before destruction. This should be configurable on note creation. For example, when a user creates a note, the user can select that the note can only be viewed 3 times. Then, the URL is sent to 3 recipients. Questions include whether this will break the existing on-disk encrypted format, or if we rely on an external file, such as we're doing with the user-supplied passphrases and the duress key. Also, how would this get implemented with user-supplied passphrases? Should each recipient get their own URL, which means their own note? That way, each user could not destroy the note of the others.