Feature request list

From Bitmessage Wiki
Revision as of 01:44, 23 July 2013 by Anon4life (talk | contribs)
Jump to navigation Jump to search

This page lists features requested from users

GUI

Menu

File

Settings

  • UI setting to stop trying to send messages after X hours/days/months.

Help

  • Exact steps for setting a home router to accept all TCP/IP connections - for users willing to help out but REALLY uncomfortable with network settings
    • Link to http://portforward.com/ (This page may lead to bad user experience due to massive advertisments and product placement)

Tabs

Inbox

  • A search feature
  • Sort inbox by the time the message was sent, not received (could be a sorting option if a 'sent' column is added or if you could switch between 'sent' and 'received')
    • Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.
    • Is there another way to accomplish this then? (Maybe the nodes send the messages out in the order that they received them?) Something to add a little bit of order to this issue. Yes, people could lie (or have a clock this is very off) but for the most part it would help keep it in some order. Also they couldn't send one more than 2 days old, nor could they send a message from too far in the future (this is checked isn't it?).
    • Atheros: Yes, it is checked (messages from more than 3 hours in the future are ignored). I agree that this would be a nice feature but I'm not sure how I would implement this. When people click the column header to sort by the received time they will expect that it sort by the date shown so if I were to have it sort by the timestamp date but show the receive date (which would be easy to do) I have a feeling people would complain that it is buggy.
    • What about the ability to right click on the sort-by bar and specify what fields are shown. That would allow you to keep it like it is by default but add the following fields; "Sent Time", "Size", "Address Version", "In address book", etc. I agree that sorting by received time should do just that. Are messages not transferred in the order they are received by the node? Essentially, the node would keep up with the order that it received the message and when my client downloads them, it gets them in that order?
    • Atheros: They aren't and even if they were they would still get mixed up because you connect to multiple peers.
    • What about getting a time signature from outside? Either referring to a random, but stable source (like holding up the newspaper in a kidnapping video) or (decentralized) by creating a Blockchain like Bitcoin does (but throwing away old timestamps and limiting it to only parts of the streams).
  • Mark a read message as unread (In addition to the star/flag/highlight feature that should be added).
    • I have this feature pretty much done, but I'll wait to push the commit until the mainline code works on Linux again. --Nimda (talk) 22:07, 14 July 2013 (CDT)
  • Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.
    • Current workaround: edit one of the fields (like Received) to include a character like !. Then sorting by received time will show those messages first.
  • Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders. Rules would be too much to program unless someone else wants to tackle it. Folders we could do someday but it will not be high on my list of priorities.
  • Do not display broadcast messages in the inbox that you sent. EX: I send a message to a mailing list and I get a reply of my own message in the inbox.
    • Could be checked by comparing incoming broadcasts with sent messages to the same address, if the text is exactly the same, do not display. Open to suggestions.
  • When you are replying to a message, populate the 'from' field too. It should be the address the message was sent to.
  • Option to automatically add new subscriptions to address book list and/or add option 'Add to Address Book' to context menu in Subscription list
  • Option (or hard-coded) for delay before "new message" tool tip appears, especially when starting the client (maybe set separately): e.g. wait 30 seconds (after the first message is received) before alerting about 10 new messages. Or, better: change the "new message" tooltip text to "x new messages" without issuing a new popup (plus its sound that gets annoying when repeated frequently in a row).

Send

  • Built in image inlining (I guess I'll work on this) --Nimda (talk) 22:09, 14 July 2013 (CDT)
  • Built in text editor to send rich text natively. Someone else may work on this but I would prefer to keep it simple. It isn't as simple as just sending HTML as the client doesn't display HTML from strangers.
    • What about Markdown or similar structured Text? It would still be readable in plaintext and provide danger-free rich-text.
  • Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.
    • This is like showing a percentage complete on a Bitcoin block. Vanitygen shows the time until 50% probability, but I think that's a bit too much. Time POW took sounds fine, though.
    • Atheros: Indeed, there is no such thing as being some-percentage complete. The amount of time until you reach 50% probability-of-completion is constant even while doing work. This is important with Vanitygen so that you don't sit there for 1000 years trying to find a particular address but with bitmessage everyone knows how long things take: a number of minutes or possibly hours.
  • View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.
  • UI setting to stop trying to send messages after X hours/days/months.
  • Ability to create subfolders and move outbox items into them. Also a rules dialog for automatically classifying new mail into subfolders. Rules would be too much to program unless someone else wants to tackle it. Folders we could do someday but it will not be high on my list of priorities.
  • Add 'Cancel' when sending message to clear form fields. Please check the accepted requests section below before adding requests.
  • Add ability to send a copy to oneself. Like this one could keep the "sent" out-box in sync on several computers. (Being optional, only those who need it would use it as it increases the POW.)

Sent

  • A search feature
  • Ability to cancel sending a Message if POW has not yet been completed.

Your Identities

  • Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy)
    • It's not difficult to remove identities from keys.dat with a text editor. Maybe we should keep it this way to prevent accidental deletions. --Nimda (talk) 20:37, 12 June 2013 (CDT)
  • When creating adresses: Field for "Label (not shown to anyone except you)" for deterministic addresses too.

Subscriptions

Address Book

  • On Address book tab, add right-click option to add person to subscription list (easy)
    • (Merged) Pull request 212. --Nimda (talk) 21:00, 12 June 2013 (CDT)
  • Groups in address book, sending a message to the group will message all of the users of that group. (keep the 'name or label' and 'address' but allow the address section to contain multiple addresses separated by semicolon?)
  • View the PoW required for an address.
  • Double clicking on address in Address Book should 'send to' rather than edit the field. Right click to edit would be better since this is a much less often used feature.
  • (Regardless of what double-click does) could "edit label" please be added to the context menu. It will not occur to Windows-only users to double-click.
  • Show 'Name or Label' in/beside To: field after adding address, or even just show the name/label if it is found in the address book and do translation when sending.
  • Alert "address already in addressbook as 'name of contact'" when trying to add contact with BM-address that is already in the list. For now the GUI just accepts the new entry and does nothing at all. You might want to suggest to rename the old contact to the new name.
  • Creating an address (deterministic or otherwise). Either there or in the help section explain the impact on message receiver. If none, say none. Thanks.
  • "Subscribe to this Address" could be a checkbox (or a checkable context menu item) instead of copying the address to the subscriptions. Then show the subscribed addresses in the subscriptions as ghost copies in a different style. Alternatively, merge the Address Book and the Subscriptions.

Blacklist

  • Blacklist should also scan the mailinglists to filter out "ostensibly" blacklisted addresses.

Other

Network Status

  • Network info in the status bar. Current upload/download speeds as well as total uploaded/downloaded since startup. ATHEROS EDIT: The current bandwidth usage is almost always 0. I suppose I could add a total uploaded/downloaded counter.
  • Clicking the red/yellow or green balloon now shows the explanations. Can it also point to he help which would describe the exact steps on how to set up a home router to accept incoming connections - for people who wish to help but are REALLY uncomfortable with routers

Windows System Tray

  • Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)
  • Change the tray icon graphic to reflect when a new message comes in. This could be standard and used when the balloon is disabled (or in conjunction). Also allows the user to see that they have messages if they missed the popup.
  • Clicking the "Connected" item in the tray context menu should bring up the "network status" tab (just like "send", "subscribe" and "address book" bring up the respective tabs). Also, all of them should bring the BM window to front.

overall or unclassified

  • Add Multi-language Support (add to site .xml file with language strings )
  • Sounds (easy. This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)
  • User can adjust font and font size for easy reading.
  • GUI interface for adding attachments to outgoing message and opening incoming attachments.
  • The ability to inform and update the client via the GUI.
  • A GUI interface to send and receive public keys and to set levels of trust. So, if I set a high level of trust for a public key signed by John Smith, subsequent messages received that are signed by that key will indicate that they are from John Smith. Maybe optional color coding to indicate the level of trust?
    • Atheros: Messages received that are signed by that key already indicate that they are from John Smith. Isn't this just the same thing as adding colors to address book?
  • Some kind of visual representation of the keys, like Identicons

Network

  • Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)
  • Ability to disable the built-in defaultKnownNodes, useful for LAN use or people running their own BitMessage network (no need to interact outside of the designated network). (easy)
    • ATHEROS EDIT: I'm having trouble figuring out a good UI for this. Can there simply be an option which you can add to keys.dat, for example: 'ignoredefaultnodes = true' which would cause Bitmessage to not only ignore the defaultKnownNodes but also addr messages? Then you can use the as-yet-to-be-added UI feature that lets you add your own IP?
    • That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?
  • Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)).
    • ATHEROS EDIT: How about being able to add an IP in the user interface?
    • I think that should be an option as well (see above define your own known nodes feature request) but would not allow a p2p style network unless you input every ip in use (since private ip addresses are blocked).

API

  • API ackdata lookup (easy, although I would like to make some internal Bitmessage changes first- for example, 'sentmessage' isn't a very useful status, but 'ackreceived' is better)
  • Refresh GUI inbox (for example after deleting messages)
    • This is actually done automatically
  • Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?
  • Add/Remove and Retrieve addresses from address book.
  • Add/Remove addresses to/from Blacklist/Whitelist.
    • Change the status between blacklist and whitelist
  • Add/Remove address to/from identities.
  • Extending the get Method to get the complete address block from an address.
  • Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)
  • Ability to check the status of sent messages and being able to trash them.
    • Status check can be done with the getStatus Method already
  • Find the PoW requirement for an address (not local).

Backend

  • Encrypt keys.dat file and messages.dat file with a password. (difficult) EDIT: I spent some time searching for a way to encrypt the messages.dat file and only found proprietary solutions. EDIT: Bitcoin does this with it's wallet.dat, I'm sure the source code would reveal the method, also I don't see why gpg in symmetric mode wouldn't work.
  • Offline mode (easy)
  • Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)
  • Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)
  • Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)
  • Special Address Behavior, Allow setting for maximum message size to be broadcasted by pseudo-mailing-list. Currently they can be bogged down with very big messages.
  • Process two messages instead of one at a time. A client could get caught up on one hard POW and not be able to send other messages until they delete it from the sent tab.
    • The ability to set the maximum POW time per message before suspend it and going to the next would probably be better.
    • Alternative: Ability to set the number of processed messages according to the number of cores.
  • Make this work without causing any issues (it is an un-intended use): Many users with the same address (created by a passphrase or shared key) sending p2p and broadcast messages in-between each other.
    • Option to set an address as DML
  • Allow white-black lists per address (White-listed mailing list without dedicating a client would be one of the uses).
  • Include the version of bitmessage in the keys.dat file. Or provide it over the API. That way applications interfacing to bitmessage know what version they are dealing with.
  • Prioritize outgoing messages. The priority order should be, Marked urgent, Contact in address book, Contact in subscriptions list, Standard, Low priority. PoW should be paused to allow the completion of any message in a higher tier. This would allow non-urgent (low priority) messages to be sent as a part of the backend to clients, without interfering with the user. Example would be a twitmessage (twitter) client sending notifications. Even if this was possible with only two tiers, one for user messages, another for backend messages, then that would be great.
  • Option to use keyfiles when generating either type of address. (or encrypting the keys.dat/etc files in the future)
  • Add CPU and Network Usage control.(easy)--Arthur200000 (talk) 23:27, 30 May 2013 (CDT)
  • Create a Maildir interface so normal MUAs can be used for incoming mail.
    • This is actually not "normal". The Windows world does not has this "feature"
  • Create a SMTP interface so normal MUAs can be used for outgoing mail (like [1]). Non-bitmessage message could/should be forwarded to a regular SMTP server.
    • Forwarding sounds dangerous, it can happen accidently, also you need a gateway, that accepts your sender.

Wiki/Forum

  • Add MD5 checksum and PGP signature to the download area. (easy)
    • Why not just sign the application?
  • Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.
  • Add ability to specify bitmessage address for wiki/forum password recovery/reset
  • Add a ed2k link for faster downloading.(easy)
  • Provide optimized apps(SSE,etc.)for lower CPU usage and faster working.(easy)

Accepted Requests (Implemented in version 0.3.0 and before)

  • Show addresses without the hyphen (easy, under discussion) abandoned
  • Accept addresses without the hyphen (easy) Done, accepts address without "BM-"
  • Ability to trash sent messages(easy) Done
  • Clear the 'Send' tab after sending message or when acknowledgement received. (easy) Done
  • Trim input when adding an subscription or address book address (very easy) Done
  • Do not open new messages automatically, and indicate if a message has been read. (----) Done
  • Confirm delete? (Doing the above might fix this issue as well, I was deleting a message and a new message came in so I deleted the new message). (----) Basically done- see above.
  • Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address" Done
  • Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) Done
  • Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) You can already do this.
  • Ability to disable and re-enable a subscription address. (easy) Done
  • Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.) Done. After trashing a message, restart Bitmessage immediately. There currently still is no notification that restarting Bitmessage is necessary.
  • Cancel sending a new message (clear all of the fields) I would rather not add another button; please clear them manually for now.
  • Add support for SOCKS5 proxies (difficult) Done
  • Notification or Warning when sending a broadcast that broadcasts are sent in plaintext and anyone can receive it "Broadcast to anyone who is subscribed to your address" is vague and could give a sense of false security. Done
  • RPC API (difficult) Done
  • Portable mode (easy) Done
  • Headless operation.Done
Retrieved from "https://wiki.bitmessage.org/index.php?title=Feature_request_list&oldid=19329"