https://wiki.bitmessage.org/api.php?action=feedcontributions&user=Dok&feedformat=atomBitmessage Wiki - User contributions [en]2024-03-28T12:34:24ZUser contributionsMediaWiki 1.34.0https://wiki.bitmessage.org/index.php?title=Compiling_instructions&diff=19498Compiling instructions2013-08-09T16:45:58Z<p>Dok: /* Linux */</p>
<hr />
<div>This page should help novice users run Bitmessage from the source code files.<br />
<br />
= Linux =<br />
== Fedora + RHEL ==<br />
'''Install dependencies:'''<br />
<br />
''Fedora and RHEL6 do not support EC in OpenSSL. Therefore we need [http://linux.ringingliberty.com/bitcoin/ Ringing Liberty's bitcoin repository] to get a compatible library.''<br />
<br />
Repository for Fedora:<br />
su -c 'yum install http://linux.ringingliberty.com/bitcoin/f18/x86_64/bitcoin-release-1-4.noarch.rpm'<br />
or this one for RedHat Enterprise Linux (RHEL):<br />
su -c 'yum install http://linux.ringingliberty.com/bitcoin/el6/x86_64/bitcoin-release-1-4.noarch.rpm'<br />
Install dependencies:<br />
su -c 'yum install python git openssl-compat-bitcoin-libs'<br />
'''Download''' Bitmessage from GIT:<br />
git clone https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage<br />
'''Run''' Bitmessage:<br />
cd $HOME/PyBitmessage/src/ && LD_LIBRARY_PATH="/opt/openssl-compat-bitcoin/lib/" python bitmessagemain.py<br />
<br />
== Other Distros ==<br />
<br />
<small>''Note for Debian Squeeze (6.0) users: Debian Squeeze does not offer packages (like Python, OpenSSL) in versions that are needed for Bitmessage. You can still try to [https://github.com/Bitmessage/PyBitmessage/issues/47#issuecomment-17774377 work around these problems].''</small><br />
<br />
<small>For Whonix (0.5.6) installation, follow the steps for Debian.</small><br />
<br />
; Install dependencies:<br />
: APT-based distributions (Debian, Ubuntu): <code>sudo apt-get install python openssl git python-qt4</code><br />
: Raspberry Pi (Raspbian "wheezy"): <code>sudo apt-get install python-qt4</code><br />
: RPM-based distributions (Red Hat, Fedora): <code>sudo yum install python openssl git</code><br />
: Arch: <code>sudo pacman -S python2 openssl git python2-pyqt4</code><br />
<br />
; Download and run Bitmessage:<br />
git clone <nowiki>https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage</nowiki><br />
cd $HOME/PyBitmessage/src/ && python bitmessagemain.py<br />
<br />
==Upgrading==<br />
; To upgrade Bitmessage run the following commands:<br />
cd $HOME/PyBitmessage/src/ <br />
git pull origin master<br />
python bitmessagemain.py<br />
<br />
= OS X =<br />
== With Homebrew package manager ==<br />
; Setup<br />
First, make sure you have not already installed Macports. Having both macports and homebrew on the same system is a recipe for disaster. <br />
Install Homebrew: <br />
ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"<br />
<br />
Update Python:<br />
brew install python<br />
<br />
; Install dependencies:<br />
brew install pyqt openssl<br />
<br />
; Download and run<br />
cd ~/Desktop<br />
git clone git://github.com/Bitmessage/PyBitmessage.git<br />
cd PyBitmessage<br />
python src/bitmessagemain.py<br />
<br />
== With macports package manager ==<br />
First, make sure you have not already installed Homebrew. Having both macports and homebrew on the same system is a recipe for disaster. <br />
Installing with macports or homebrew essentially has the same effect. Homebrew does some things better than ports, and ports does some things better than brew. If old-school floats your boat, these instructions are for you. <br />
<br />
; Select the macports installation that is right for your version of osx<br />
https://www.macports.org/install.php<br />
<br />
; Install dependencies and needed tools<br />
sudo port install python27 py27-pyqt4 openssl<br />
sudo port install git-core +svn +doc +bash_completion +gitweb<br />
<br />
; Download and run<br />
cd ~/Desktop<br />
git clone git://github.com/Bitmessage/PyBitmessage.git<br />
cd PyBitmessage<br />
python2.7 src/bitmessagemain.py<br />
<br />
= Windows =<br />
# Download and install the latest revision of Python 2.7 (currently Python 2.7.3 from [http://www.python.org/download/releases/2.7.3/ here]). The ''Windows x86 MSI Installer'' is the right choice for most people. (64-bit users may want the 64-bit version).<br />
# Test that it installed:<br />
## Open a command prompt by going to Start > Run. Type 'cmd' then press enter.<br />
## type 'python'. If python is installed, you should see the python version and the prompt: '>>>'<br />
## If you see a message such as: "'Python is not recognized as an internal or external command..." then you must add the python path to your path environmental variable:<br />
### Find the location where Python was installed (in particular, the location where python.exe exists). It might simply be in c:\Python2.7 <br />
### Follow [http://www.computerhope.com/issues/ch000549.htm these directions] to add the Python path to your path variable.<br />
### Close the command prompt window and reopen it. <br />
### Try running 'python' again.<br />
##Press Ctrl-Z to exit Python.<br />
# Bitmessage has two dependencies. The first is PyQt. Download and install PyQt from [http://www.riverbankcomputing.com/software/pyqt/download here]. You will want the Binary Package since it is already compiled for you. Be sure to select the version for Python 2.7. It is labeled as Py2.7. <br />
# The second dependency is OpenSSL which you can download from [http://slproweb.com/products/Win32OpenSSL.html here]. There you will also notice the link to download the Visual C++ 2008 program in case you also find that you need that as well. (The OpenSSL installer will complain if you need to install the Visual C++ Redistributable.)<br />
# Download the source code for PyBitmessage from GitHub. If it is in a zip file, you will need to extract it. There should be a few files and a few folders where one of the folders is 'src'. <br />
# To run Bitmessage, navigate into the 'src' folder and then double click on the bitmessagemain.py file, or in a command prompt, change directories to the 'src' directory which holds bitmessagemain.py and type 'python bitmessagemain.py'. <br />
<br />
== If you change user interface files ==<br />
You can use Qt's Designer application to modify the user interface. After you do this, you will need to 'compile' .ui files into .py files. <br />
# In a command prompt, change directories to the directory of your .ui file.<br />
# Run 'pyuic4 example.ui > example.py' If you get a message similar to 'pyuic4 is not recognized as an internal or external command' then you must add the PyQt directory to your system's path variable. This directory should hold pyuic4.bat. It might be in C:\Python27\Lib\site-packages\PyQt4. Remember to close the command window and reopen it after you change your path variable.<br />
<br />
If you add icons to bitmessage_icons.qrc, then you must run this command:<br />
pyrcc4 bitmessage_icons.qrc -o bitmessage_icons_rc.py<br />
<br />
== Optional: Compile into a stand-alone EXE ==<br />
# Download [http://www.pyinstaller.org/ PyInstaller].<br />
# Copy Bitmessage's 'src' directory to the PyInstaller directory (which contains pyinstaller.py). <br />
# Run 'pyinstaller.py --onefile --noconsole --icon="src\images\can-icon.ico" src\bitmessagemain.py'<br />
This won't include the OpenSSL DLL file in the EXE; if you send it to someone who doesn't have OpenSSL installed, it will not run. To include the DLL file in the EXE, you must follow these steps:<br />
# After following the steps above, you will see that pyinstaller created a folder called bitmessagemain. In that folder is a file: bitmessagemain.spec. Open it with a text editor.<br />
# Below the line "a.datas," add this line: <code>a.binaries + [('libeay32.dll', 'c:\\windows\\system32\\libeay32.dll', 'BINARY')],</code><br />
# Save and close<br />
# Run this command: pyinstaller.py bitmessagemain/bitmessagemain.spec<br />
<br />
If you do not have the libeay32.dll you can download it here. http://www.dll-files.com/dllindex/dll-files.shtml?libeay32</div>Dokhttps://wiki.bitmessage.org/index.php?title=Compiling_instructions&diff=19497Compiling instructions2013-08-09T16:45:04Z<p>Dok: /* Upgrading */</p>
<hr />
<div>This page should help novice users run Bitmessage from the source code files.<br />
<br />
= Linux =<br />
== Fedora + RHEL ==<br />
'''Install dependencies:'''<br />
<br />
''Fedora and RHEL6 do not support EC in OpenSSL. Therefore we need [http://linux.ringingliberty.com/bitcoin/ Ringing Liberty's bitcoin repository] to get a compatible library.''<br />
<br />
Repository for Fedora:<br />
su -c 'yum install http://linux.ringingliberty.com/bitcoin/f18/x86_64/bitcoin-release-1-4.noarch.rpm'<br />
or this one for RedHat Enterprise Linux (RHEL):<br />
su -c 'yum install http://linux.ringingliberty.com/bitcoin/el6/x86_64/bitcoin-release-1-4.noarch.rpm'<br />
Install dependencies:<br />
su -c 'yum install python git openssl-compat-bitcoin-libs'<br />
'''Download''' Bitmessage from GIT:<br />
git clone https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage<br />
'''Run''' Bitmessage:<br />
cd $HOME/PyBitmessage/src/ && LD_LIBRARY_PATH="/opt/openssl-compat-bitcoin/lib/" python bitmessagemain.py<br />
<br />
== Other Distros ==<br />
<br />
<small>''Note for Debian Squeeze (6.0) users: Debian Squeeze does not offer packages (like Python, OpenSSL) in versions that are needed for Bitmessage. You can still try to [https://github.com/Bitmessage/PyBitmessage/issues/47#issuecomment-17774377 work around these problems].''</small><br />
<br />
<small>For Whonix (0.5.6) installation, follow the steps for Debian.</small><br />
<br />
; Install dependencies:<br />
: APT-based distributions (Debian, Ubuntu): <code>sudo apt-get install python openssl git python-qt4</code><br />
: Raspberry Pi (Raspbian "wheezy"): <code>sudo apt-get install python-qt4</code><br />
: RPM-based distributions (Red Hat, Fedora): <code>sudo yum install python openssl git</code><br />
: Arch: <code>sudo pacman -S python2 openssl git python2-pyqt4</code><br />
<br />
; Download and run Bitmessage:<br />
git clone <nowiki>https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage</nowiki><br />
cd $HOME/PyBitmessage/src/ && python bitmessagemain.py<br />
<br />
==Upgrading==<br />
;cd $HOME/PyBitmessage/src/ <br />
;git pull origin master<br />
;python bitmessagemain.py<br />
<br />
= OS X =<br />
== With Homebrew package manager ==<br />
; Setup<br />
First, make sure you have not already installed Macports. Having both macports and homebrew on the same system is a recipe for disaster. <br />
Install Homebrew: <br />
ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"<br />
<br />
Update Python:<br />
brew install python<br />
<br />
; Install dependencies:<br />
brew install pyqt openssl<br />
<br />
; Download and run<br />
cd ~/Desktop<br />
git clone git://github.com/Bitmessage/PyBitmessage.git<br />
cd PyBitmessage<br />
python src/bitmessagemain.py<br />
<br />
== With macports package manager ==<br />
First, make sure you have not already installed Homebrew. Having both macports and homebrew on the same system is a recipe for disaster. <br />
Installing with macports or homebrew essentially has the same effect. Homebrew does some things better than ports, and ports does some things better than brew. If old-school floats your boat, these instructions are for you. <br />
<br />
; Select the macports installation that is right for your version of osx<br />
https://www.macports.org/install.php<br />
<br />
; Install dependencies and needed tools<br />
sudo port install python27 py27-pyqt4 openssl<br />
sudo port install git-core +svn +doc +bash_completion +gitweb<br />
<br />
; Download and run<br />
cd ~/Desktop<br />
git clone git://github.com/Bitmessage/PyBitmessage.git<br />
cd PyBitmessage<br />
python2.7 src/bitmessagemain.py<br />
<br />
= Windows =<br />
# Download and install the latest revision of Python 2.7 (currently Python 2.7.3 from [http://www.python.org/download/releases/2.7.3/ here]). The ''Windows x86 MSI Installer'' is the right choice for most people. (64-bit users may want the 64-bit version).<br />
# Test that it installed:<br />
## Open a command prompt by going to Start > Run. Type 'cmd' then press enter.<br />
## type 'python'. If python is installed, you should see the python version and the prompt: '>>>'<br />
## If you see a message such as: "'Python is not recognized as an internal or external command..." then you must add the python path to your path environmental variable:<br />
### Find the location where Python was installed (in particular, the location where python.exe exists). It might simply be in c:\Python2.7 <br />
### Follow [http://www.computerhope.com/issues/ch000549.htm these directions] to add the Python path to your path variable.<br />
### Close the command prompt window and reopen it. <br />
### Try running 'python' again.<br />
##Press Ctrl-Z to exit Python.<br />
# Bitmessage has two dependencies. The first is PyQt. Download and install PyQt from [http://www.riverbankcomputing.com/software/pyqt/download here]. You will want the Binary Package since it is already compiled for you. Be sure to select the version for Python 2.7. It is labeled as Py2.7. <br />
# The second dependency is OpenSSL which you can download from [http://slproweb.com/products/Win32OpenSSL.html here]. There you will also notice the link to download the Visual C++ 2008 program in case you also find that you need that as well. (The OpenSSL installer will complain if you need to install the Visual C++ Redistributable.)<br />
# Download the source code for PyBitmessage from GitHub. If it is in a zip file, you will need to extract it. There should be a few files and a few folders where one of the folders is 'src'. <br />
# To run Bitmessage, navigate into the 'src' folder and then double click on the bitmessagemain.py file, or in a command prompt, change directories to the 'src' directory which holds bitmessagemain.py and type 'python bitmessagemain.py'. <br />
<br />
== If you change user interface files ==<br />
You can use Qt's Designer application to modify the user interface. After you do this, you will need to 'compile' .ui files into .py files. <br />
# In a command prompt, change directories to the directory of your .ui file.<br />
# Run 'pyuic4 example.ui > example.py' If you get a message similar to 'pyuic4 is not recognized as an internal or external command' then you must add the PyQt directory to your system's path variable. This directory should hold pyuic4.bat. It might be in C:\Python27\Lib\site-packages\PyQt4. Remember to close the command window and reopen it after you change your path variable.<br />
<br />
If you add icons to bitmessage_icons.qrc, then you must run this command:<br />
pyrcc4 bitmessage_icons.qrc -o bitmessage_icons_rc.py<br />
<br />
== Optional: Compile into a stand-alone EXE ==<br />
# Download [http://www.pyinstaller.org/ PyInstaller].<br />
# Copy Bitmessage's 'src' directory to the PyInstaller directory (which contains pyinstaller.py). <br />
# Run 'pyinstaller.py --onefile --noconsole --icon="src\images\can-icon.ico" src\bitmessagemain.py'<br />
This won't include the OpenSSL DLL file in the EXE; if you send it to someone who doesn't have OpenSSL installed, it will not run. To include the DLL file in the EXE, you must follow these steps:<br />
# After following the steps above, you will see that pyinstaller created a folder called bitmessagemain. In that folder is a file: bitmessagemain.spec. Open it with a text editor.<br />
# Below the line "a.datas," add this line: <code>a.binaries + [('libeay32.dll', 'c:\\windows\\system32\\libeay32.dll', 'BINARY')],</code><br />
# Save and close<br />
# Run this command: pyinstaller.py bitmessagemain/bitmessagemain.spec<br />
<br />
If you do not have the libeay32.dll you can download it here. http://www.dll-files.com/dllindex/dll-files.shtml?libeay32</div>Dokhttps://wiki.bitmessage.org/index.php?title=Compiling_instructions&diff=19496Compiling instructions2013-08-09T16:44:43Z<p>Dok: /* Other Distros */</p>
<hr />
<div>This page should help novice users run Bitmessage from the source code files.<br />
<br />
= Linux =<br />
== Fedora + RHEL ==<br />
'''Install dependencies:'''<br />
<br />
''Fedora and RHEL6 do not support EC in OpenSSL. Therefore we need [http://linux.ringingliberty.com/bitcoin/ Ringing Liberty's bitcoin repository] to get a compatible library.''<br />
<br />
Repository for Fedora:<br />
su -c 'yum install http://linux.ringingliberty.com/bitcoin/f18/x86_64/bitcoin-release-1-4.noarch.rpm'<br />
or this one for RedHat Enterprise Linux (RHEL):<br />
su -c 'yum install http://linux.ringingliberty.com/bitcoin/el6/x86_64/bitcoin-release-1-4.noarch.rpm'<br />
Install dependencies:<br />
su -c 'yum install python git openssl-compat-bitcoin-libs'<br />
'''Download''' Bitmessage from GIT:<br />
git clone https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage<br />
'''Run''' Bitmessage:<br />
cd $HOME/PyBitmessage/src/ && LD_LIBRARY_PATH="/opt/openssl-compat-bitcoin/lib/" python bitmessagemain.py<br />
<br />
== Other Distros ==<br />
<br />
<small>''Note for Debian Squeeze (6.0) users: Debian Squeeze does not offer packages (like Python, OpenSSL) in versions that are needed for Bitmessage. You can still try to [https://github.com/Bitmessage/PyBitmessage/issues/47#issuecomment-17774377 work around these problems].''</small><br />
<br />
<small>For Whonix (0.5.6) installation, follow the steps for Debian.</small><br />
<br />
; Install dependencies:<br />
: APT-based distributions (Debian, Ubuntu): <code>sudo apt-get install python openssl git python-qt4</code><br />
: Raspberry Pi (Raspbian "wheezy"): <code>sudo apt-get install python-qt4</code><br />
: RPM-based distributions (Red Hat, Fedora): <code>sudo yum install python openssl git</code><br />
: Arch: <code>sudo pacman -S python2 openssl git python2-pyqt4</code><br />
<br />
; Download and run Bitmessage:<br />
git clone <nowiki>https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage</nowiki><br />
cd $HOME/PyBitmessage/src/ && python bitmessagemain.py<br />
<br />
=Upgrading=<br />
;cd $HOME/PyBitmessage/src/ <br />
;git pull origin master<br />
;python bitmessagemain.py<br />
<br />
= OS X =<br />
== With Homebrew package manager ==<br />
; Setup<br />
First, make sure you have not already installed Macports. Having both macports and homebrew on the same system is a recipe for disaster. <br />
Install Homebrew: <br />
ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"<br />
<br />
Update Python:<br />
brew install python<br />
<br />
; Install dependencies:<br />
brew install pyqt openssl<br />
<br />
; Download and run<br />
cd ~/Desktop<br />
git clone git://github.com/Bitmessage/PyBitmessage.git<br />
cd PyBitmessage<br />
python src/bitmessagemain.py<br />
<br />
== With macports package manager ==<br />
First, make sure you have not already installed Homebrew. Having both macports and homebrew on the same system is a recipe for disaster. <br />
Installing with macports or homebrew essentially has the same effect. Homebrew does some things better than ports, and ports does some things better than brew. If old-school floats your boat, these instructions are for you. <br />
<br />
; Select the macports installation that is right for your version of osx<br />
https://www.macports.org/install.php<br />
<br />
; Install dependencies and needed tools<br />
sudo port install python27 py27-pyqt4 openssl<br />
sudo port install git-core +svn +doc +bash_completion +gitweb<br />
<br />
; Download and run<br />
cd ~/Desktop<br />
git clone git://github.com/Bitmessage/PyBitmessage.git<br />
cd PyBitmessage<br />
python2.7 src/bitmessagemain.py<br />
<br />
= Windows =<br />
# Download and install the latest revision of Python 2.7 (currently Python 2.7.3 from [http://www.python.org/download/releases/2.7.3/ here]). The ''Windows x86 MSI Installer'' is the right choice for most people. (64-bit users may want the 64-bit version).<br />
# Test that it installed:<br />
## Open a command prompt by going to Start > Run. Type 'cmd' then press enter.<br />
## type 'python'. If python is installed, you should see the python version and the prompt: '>>>'<br />
## If you see a message such as: "'Python is not recognized as an internal or external command..." then you must add the python path to your path environmental variable:<br />
### Find the location where Python was installed (in particular, the location where python.exe exists). It might simply be in c:\Python2.7 <br />
### Follow [http://www.computerhope.com/issues/ch000549.htm these directions] to add the Python path to your path variable.<br />
### Close the command prompt window and reopen it. <br />
### Try running 'python' again.<br />
##Press Ctrl-Z to exit Python.<br />
# Bitmessage has two dependencies. The first is PyQt. Download and install PyQt from [http://www.riverbankcomputing.com/software/pyqt/download here]. You will want the Binary Package since it is already compiled for you. Be sure to select the version for Python 2.7. It is labeled as Py2.7. <br />
# The second dependency is OpenSSL which you can download from [http://slproweb.com/products/Win32OpenSSL.html here]. There you will also notice the link to download the Visual C++ 2008 program in case you also find that you need that as well. (The OpenSSL installer will complain if you need to install the Visual C++ Redistributable.)<br />
# Download the source code for PyBitmessage from GitHub. If it is in a zip file, you will need to extract it. There should be a few files and a few folders where one of the folders is 'src'. <br />
# To run Bitmessage, navigate into the 'src' folder and then double click on the bitmessagemain.py file, or in a command prompt, change directories to the 'src' directory which holds bitmessagemain.py and type 'python bitmessagemain.py'. <br />
<br />
== If you change user interface files ==<br />
You can use Qt's Designer application to modify the user interface. After you do this, you will need to 'compile' .ui files into .py files. <br />
# In a command prompt, change directories to the directory of your .ui file.<br />
# Run 'pyuic4 example.ui > example.py' If you get a message similar to 'pyuic4 is not recognized as an internal or external command' then you must add the PyQt directory to your system's path variable. This directory should hold pyuic4.bat. It might be in C:\Python27\Lib\site-packages\PyQt4. Remember to close the command window and reopen it after you change your path variable.<br />
<br />
If you add icons to bitmessage_icons.qrc, then you must run this command:<br />
pyrcc4 bitmessage_icons.qrc -o bitmessage_icons_rc.py<br />
<br />
== Optional: Compile into a stand-alone EXE ==<br />
# Download [http://www.pyinstaller.org/ PyInstaller].<br />
# Copy Bitmessage's 'src' directory to the PyInstaller directory (which contains pyinstaller.py). <br />
# Run 'pyinstaller.py --onefile --noconsole --icon="src\images\can-icon.ico" src\bitmessagemain.py'<br />
This won't include the OpenSSL DLL file in the EXE; if you send it to someone who doesn't have OpenSSL installed, it will not run. To include the DLL file in the EXE, you must follow these steps:<br />
# After following the steps above, you will see that pyinstaller created a folder called bitmessagemain. In that folder is a file: bitmessagemain.spec. Open it with a text editor.<br />
# Below the line "a.datas," add this line: <code>a.binaries + [('libeay32.dll', 'c:\\windows\\system32\\libeay32.dll', 'BINARY')],</code><br />
# Save and close<br />
# Run this command: pyinstaller.py bitmessagemain/bitmessagemain.spec<br />
<br />
If you do not have the libeay32.dll you can download it here. http://www.dll-files.com/dllindex/dll-files.shtml?libeay32</div>Dokhttps://wiki.bitmessage.org/index.php?title=Timeservice_Broadcast&diff=19220Timeservice Broadcast2013-07-11T12:49:04Z<p>Dok: /* Comparison to echo servers */</p>
<hr />
<div>The Timeservice Broadcast sends network heartbeats in regular intervals, currently every 10 minutes.<br />
== Usage ==<br />
Subscribtion to the Address '''BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash''' is required. After subscribing, the client will receive a message every 10 minutes if he is connected to the core network. The subscription can be disabled or deleted any time to stop the messages from clogging up the inbox.<br />
<br />
'''This is not an echo service, it will not automatically reply to messages sent to it, however, the admin sometimes does manually reply.'''<br />
<br />
== Usage scenarios ==<br />
The time service can be used for multiple purposes<br />
=== Randomnes ===<br />
The time service puts some randomnes to the network and ensures that it has always something to do.<br />
<br />
=== Connectivity check. ===<br />
If users subscribe to the time service they can verify, they are connected to the core network, in case they think something in their connection is wrong.<br />
<br />
=== Actual time telling. ===<br />
The time service tells the accurate time (it is maximum 2 minutes behind the actual time if you receive the message). In case users want to hide even the time zone they are in, they can always add the note, that the time and date they use in messages are timeservice based, this requires setting the computer clock to [http://en.wikipedia.org/wiki/UTC UTC].<br />
<br />
== Impact ==<br />
The service has no impact on the network, it causes 144 messages every 24 hours.<br />
<br />
== Comparison to echo servers ==<br />
An [[echo service]] will reply to your message. Like a mailing list, an [[echo service]] has to compute proof of work for the messages it receives. If it is under load, such as a large influx in [[echo service]] users, your reply may be further delayed. Broadcasts can support unlimited users without causing any additional load on the network, but it does not allow the user to check if he can send messages to the network.<br />
<br />
== Current Message ==<br />
The current message is the UTC time it was generated (The entry below is an actual message):<br />
<pre><br />
Bitmessage Time Service<br />
Network alive @ 11.07.2013 11:57:40 UTC<br />
This represents the Time when the Message was generated, not when the processing finished.<br />
Do not set this time as your computer time.<br />
<br />
bitmessage.ch - Free Bitmessage <-> E-Mail Gateway<br />
Bitmessage E-Mail Application - https://bitmessage.org/forum/index.php/topic,1587.0.html<br />
24x7 Mailing List - BM-GuRLKDhQA5hAhE6PDQpkcvbtt1AuXAdQ<br />
<br />
<br />
<br />
========================================<br />
Values below are for programmatic access<br />
<br />
<br />
[PROG-ACCESS]<br />
DATE=11.07.2013<br />
TIME=11:57:40<br />
UNIX=1373543860.082<br />
</pre></div>Dokhttps://wiki.bitmessage.org/index.php?title=Timeservice_Broadcast&diff=19219Timeservice Broadcast2013-07-11T12:48:03Z<p>Dok: /* Comparison to echo servers */</p>
<hr />
<div>The Timeservice Broadcast sends network heartbeats in regular intervals, currently every 10 minutes.<br />
== Usage ==<br />
Subscribtion to the Address '''BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash''' is required. After subscribing, the client will receive a message every 10 minutes if he is connected to the core network. The subscription can be disabled or deleted any time to stop the messages from clogging up the inbox.<br />
<br />
'''This is not an echo service, it will not automatically reply to messages sent to it, however, the admin sometimes does manually reply.'''<br />
<br />
== Usage scenarios ==<br />
The time service can be used for multiple purposes<br />
=== Randomnes ===<br />
The time service puts some randomnes to the network and ensures that it has always something to do.<br />
<br />
=== Connectivity check. ===<br />
If users subscribe to the time service they can verify, they are connected to the core network, in case they think something in their connection is wrong.<br />
<br />
=== Actual time telling. ===<br />
The time service tells the accurate time (it is maximum 2 minutes behind the actual time if you receive the message). In case users want to hide even the time zone they are in, they can always add the note, that the time and date they use in messages are timeservice based, this requires setting the computer clock to [http://en.wikipedia.org/wiki/UTC UTC].<br />
<br />
== Impact ==<br />
The service has no impact on the network, it causes 144 messages every 24 hours.<br />
<br />
== Comparison to echo servers ==<br />
An [[echo service]] will reply to your message. Like a mailing list, an echo service has to compute proof of work for the messages it receives. If it is under load, such as a large influx in echo service users, your reply may be further delayed. Broadcasts can support unlimited users without causing any additional load on the network, but it does not allow the user to check if he can send messages to the network.<br />
<br />
== Current Message ==<br />
The current message is the UTC time it was generated (The entry below is an actual message):<br />
<pre><br />
Bitmessage Time Service<br />
Network alive @ 11.07.2013 11:57:40 UTC<br />
This represents the Time when the Message was generated, not when the processing finished.<br />
Do not set this time as your computer time.<br />
<br />
bitmessage.ch - Free Bitmessage <-> E-Mail Gateway<br />
Bitmessage E-Mail Application - https://bitmessage.org/forum/index.php/topic,1587.0.html<br />
24x7 Mailing List - BM-GuRLKDhQA5hAhE6PDQpkcvbtt1AuXAdQ<br />
<br />
<br />
<br />
========================================<br />
Values below are for programmatic access<br />
<br />
<br />
[PROG-ACCESS]<br />
DATE=11.07.2013<br />
TIME=11:57:40<br />
UNIX=1373543860.082<br />
</pre></div>Dokhttps://wiki.bitmessage.org/index.php?title=Compiling_instructions&diff=19200Compiling instructions2013-07-11T02:44:27Z<p>Dok: /* Other Distros */</p>
<hr />
<div>This page should help novice users run Bitmessage from the source code files.<br />
<br />
= Linux =<br />
== Fedora + RHEL ==<br />
'''Install dependencies:'''<br />
<br />
''Fedora and RHEL6 do not support EC in OpenSSL. Therefore we need [http://linux.ringingliberty.com/bitcoin/ Ringing Liberty's bitcoin repository] to get a compatible library.''<br />
<br />
Repository for Fedora:<br />
su -c 'yum install http://linux.ringingliberty.com/bitcoin/f18/x86_64/bitcoin-release-1-4.noarch.rpm'<br />
or this one for RedHat Enterprise Linux (RHEL):<br />
su -c 'yum install http://linux.ringingliberty.com/bitcoin/el6/x86_64/bitcoin-release-1-4.noarch.rpm'<br />
Install dependencies:<br />
su -c 'yum install python git openssl-compat-bitcoin-libs'<br />
'''Download''' Bitmessage from GIT:<br />
git clone https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage<br />
'''Run''' Bitmessage:<br />
cd $HOME/PyBitmessage/src/ && LD_LIBRARY_PATH="/opt/openssl-compat-bitcoin/lib/" python bitmessagemain.py<br />
<br />
== Other Distros ==<br />
<br />
<small>''Note for Debian Squeeze (6.0) users: Debian Squeeze does not offer packages (like Python, OpenSSL) in versions that are needed for Bitmessage. You can still try to [https://github.com/Bitmessage/PyBitmessage/issues/47#issuecomment-17774377 work around these problems].''</small><br />
<br />
<small>For Whonix (0.5.6) installation, follow the steps for Debian.</small><br />
<br />
; Install dependencies:<br />
: APT-based distributions (Debian, Ubuntu): <code>sudo apt-get install python openssl git python-qt4</code><br />
: Raspberry Pi (Raspbian "wheezy"): <code>sudo apt-get install python-qt4</code><br />
: RPM-based distributions (Red Hat, Fedora): <code>sudo yum install python openssl git</code><br />
<br />
; Download and run Bitmessage:<br />
git clone <nowiki>https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage</nowiki><br />
cd $HOME/PyBitmessage/src/ && python bitmessagemain.py<br />
<br />
= OS X =<br />
== With Homebrew package manager ==<br />
; Setup<br />
First, make sure you have not already installed Macports. Having both macports and homebrew on the same system is a recipe for disaster. <br />
Install Homebrew: <br />
ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"<br />
<br />
Update Python:<br />
brew install python<br />
<br />
; Install dependencies:<br />
brew install pyqt openssl<br />
<br />
; Download and run<br />
cd ~/Desktop<br />
git clone git://github.com/Bitmessage/PyBitmessage.git<br />
cd PyBitmessage<br />
python src/bitmessagemain.py<br />
<br />
== With macports package manager ==<br />
First, make sure you have not already installed Homebrew. Having both macports and homebrew on the same system is a recipe for disaster. <br />
Installing with macports or homebrew essentially has the same effect. Homebrew does some things better than ports, and ports does some things better than brew. If old-school floats your boat, these instructions are for you. <br />
<br />
; Select the macports installation that is right for your version of osx<br />
https://www.macports.org/install.php<br />
<br />
; Install dependencies and needed tools<br />
sudo port install python2.7 py27-pyqt4 openssl<br />
sudo port install git-core +svn +doc +bash_completion +gitweb<br />
<br />
; Download and run<br />
cd ~/Desktop<br />
git clone git://github.com/Bitmessage/PyBitmessage.git<br />
cd PyBitmessage<br />
python2.7 src/bitmessagemain.py<br />
<br />
= Windows =<br />
# Download and install the latest revision of Python 2.7 (currently Python 2.7.3 from [http://www.python.org/download/releases/2.7.3/ here]). The ''Windows x86 MSI Installer'' is the right choice for most people. (64-bit users may want the 64-bit version).<br />
# Test that it installed:<br />
## Open a command prompt by going to Start > Run. Type 'cmd' then press enter.<br />
## type 'python'. If python is installed, you should see the python version and the prompt: '>>>'<br />
## If you see a message such as: "'Python is not recognized as an internal or external command..." then you must add the python path to your path environmental variable:<br />
### Find the location where Python was installed (in particular, the location where python.exe exists). It might simply be in c:\Python2.7 <br />
### Follow [http://www.computerhope.com/issues/ch000549.htm these directions] to add the Python path to your path variable.<br />
### Close the command prompt window and reopen it. <br />
### Try running 'python' again.<br />
##Press Ctrl-Z to exit Python.<br />
# Bitmessage has two dependencies. The first is PyQt. Download and install PyQt from [http://www.riverbankcomputing.com/software/pyqt/download here]. You will want the Binary Package since it is already compiled for you. Be sure to select the version for Python 2.7. It is labeled as Py2.7. <br />
# The second dependency is OpenSSL which you can download from [http://slproweb.com/products/Win32OpenSSL.html here]. There you will also notice the link to download the Visual C++ 2008 program in case you also find that you need that as well. (The OpenSSL installer will complain if you need to install the Visual C++ Redistributable.)<br />
# Download the source code for PyBitmessage from GitHub. If it is in a zip file, you will need to extract it. There should be a few files and a few folders where one of the folders is 'src'. <br />
# To run Bitmessage, navigate into the 'src' folder and then double click on the bitmessagemain.py file, or in a command prompt, change directories to the 'src' directory which holds bitmessagemain.py and type 'python bitmessagemain.py'. <br />
<br />
== If you change user interface files ==<br />
You can use Qt's Designer application to modify the user interface. After you do this, you will need to 'compile' .ui files into .py files. <br />
# In a command prompt, change directories to the directory of your .ui file.<br />
# Run 'pyuic4 example.ui > example.py' If you get a message similar to 'pyuic4 is not recognized as an internal or external command' then you must add the PyQt directory to your system's path variable. This directory should hold pyuic4.bat. It might be in C:\Python27\Lib\site-packages\PyQt4. Remember to close the command window and reopen it after you change your path variable.<br />
<br />
If you add icons to bitmessage_icons.qrc, then you must run this command:<br />
pyrcc4 bitmessage_icons.qrc -o bitmessage_icons_rc.py<br />
<br />
== Optional: Compile into a stand-alone EXE ==<br />
# Download [http://www.pyinstaller.org/ PyInstaller].<br />
# Copy Bitmessage's 'src' directory to the PyInstaller directory (which contains pyinstaller.py). <br />
# Run 'pyinstaller.py --onefile --noconsole --icon="src\images\can-icon.ico" src\bitmessagemain.py'<br />
This won't include the OpenSSL DLL file in the EXE; if you send it to someone who doesn't have OpenSSL installed, it will not run. To include the DLL file in the EXE, you must follow these steps:<br />
# After following the steps above, you will see that pyinstaller created a folder called bitmessagemain. In that folder is a file: bitmessagemain.spec. Open it with a text editor.<br />
# Below the line "a.datas," add this line: <code>a.binaries + [('libeay32.dll', 'c:\\windows\\system32\\libeay32.dll', 'BINARY')],</code><br />
# Save and close<br />
# Run this command: pyinstaller.py bitmessagemain/bitmessagemain.spec<br />
<br />
If you do not have the libeay32.dll you can download it here. http://www.dll-files.com/dllindex/dll-files.shtml?libeay32</div>Dokhttps://wiki.bitmessage.org/index.php?title=Compiling_instructions&diff=19191Compiling instructions2013-07-10T04:50:56Z<p>Dok: /* other Distros */</p>
<hr />
<div>This page should help novice users run Bitmessage from the source code files.<br />
<br />
= Linux =<br />
== Fedora + RHEL ==<br />
'''Install dependencies:'''<br />
<br />
''Fedora and RHEL6 do not support EC in OpenSSL. Therefore we need [http://linux.ringingliberty.com/bitcoin/ Ringing Liberty's bitcoin repository] to get a compatible library.''<br />
<br />
Repository for Fedora:<br />
su -c 'yum install http://linux.ringingliberty.com/bitcoin/f18/x86_64/bitcoin-release-1-4.noarch.rpm'<br />
or this one for RedHat Enterprise Linux (RHEL):<br />
su -c 'yum install http://linux.ringingliberty.com/bitcoin/el6/x86_64/bitcoin-release-1-4.noarch.rpm'<br />
Install dependencies:<br />
su -c 'yum install python git openssl-compat-bitcoin-libs'<br />
'''Download''' Bitmessage from GIT:<br />
git clone https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage<br />
'''Run''' Bitmessage:<br />
cd $HOME/PyBitmessage/src/ && LD_LIBRARY_PATH="/opt/openssl-compat-bitcoin/lib/" python bitmessagemain.py<br />
<br />
== Other Distros ==<br />
<br />
<small>''Note for Debian Squeeze (6.0) users: Debian Squeeze does not offer packages (like Python, OpenSSL) in versions that are needed for Bitmessage. You can still try to [https://github.com/Bitmessage/PyBitmessage/issues/47#issuecomment-17774377 work around these problems].''</small><br />
<small>For Whonix (0.5.6) installation, follow the steps for Debian.</small><br />
<br />
; Install dependencies:<br />
: APT-based distributions (Debian, Ubuntu): <code>sudo apt-get install python openssl git python-qt4</code><br />
: Raspberry Pi (Raspbian "wheezy"): <code>sudo apt-get install python-qt4</code><br />
: RPM-based distributions (Red Hat, Fedora): <code>sudo yum install python openssl git</code><br />
<br />
; Download and run Bitmessage:<br />
git clone <nowiki>https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage</nowiki><br />
cd $HOME/PyBitmessage/src/ && python bitmessagemain.py<br />
<br />
= OS X =<br />
; Setup<br />
Install Homebrew: <br />
ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"<br />
<br />
Update Python:<br />
brew install python<br />
<br />
; Install dependencies:<br />
brew install pyqt openssl<br />
<br />
; Download and run<br />
cd ~/Desktop<br />
git clone git://github.com/Bitmessage/PyBitmessage.git<br />
cd PyBitmessage<br />
python src/bitmessagemain.py<br />
<br />
= Windows =<br />
# Download and install the latest revision of Python 2.7 (currently Python 2.7.3 from [http://www.python.org/download/releases/2.7.3/ here]). The ''Windows x86 MSI Installer'' is the right choice for most people. (64-bit users may want the 64-bit version).<br />
# Test that it installed:<br />
## Open a command prompt by going to Start > Run. Type 'cmd' then press enter.<br />
## type 'python'. If python is installed, you should see the python version and the prompt: '>>>'<br />
## If you see a message such as: "'Python is not recognized as an internal or external command..." then you must add the python path to your path environmental variable:<br />
### Find the location where Python was installed (in particular, the location where python.exe exists). It might simply be in c:\Python2.7 <br />
### Follow [http://www.computerhope.com/issues/ch000549.htm these directions] to add the Python path to your path variable.<br />
### Close the command prompt window and reopen it. <br />
### Try running 'python' again.<br />
##Press Ctrl-Z to exit Python.<br />
# Bitmessage has two dependencies. The first is PyQt. Download and install PyQt from [http://www.riverbankcomputing.com/software/pyqt/download here]. You will want the Binary Package since it is already compiled for you. Be sure to select the version for Python 2.7. It is labeled as Py2.7. <br />
# The second dependency is OpenSSL which you can download from [http://slproweb.com/products/Win32OpenSSL.html here]. There you will also notice the link to download the Visual C++ 2008 program in case you also find that you need that as well. (The OpenSSL installer will complain if you need to install the Visual C++ Redistributable.)<br />
# Download the source code for PyBitmessage from GitHub. If it is in a zip file, you will need to extract it. There should be a few files and a few folders where one of the folders is 'src'. <br />
# To run Bitmessage, navigate into the 'src' folder and then double click on the bitmessagemain.py file, or in a command prompt, change directories to the 'src' directory which holds bitmessagemain.py and type 'python bitmessagemain.py'. <br />
<br />
== If you change user interface files ==<br />
You can use Qt's Designer application to modify the user interface. After you do this, you will need to 'compile' .ui files into .py files. <br />
# In a command prompt, change directories to the directory of your .ui file.<br />
# Run 'pyuic4 example.ui > example.py' If you get a message similar to 'pyuic4 is not recognized as an internal or external command' then you must add the PyQt directory to your system's path variable. This directory should hold pyuic4.bat. It might be in C:\Python27\Lib\site-packages\PyQt4. Remember to close the command window and reopen it after you change your path variable.<br />
<br />
If you add icons to bitmessage_icons.qrc, then you must run this command:<br />
pyrcc4 bitmessage_icons.qrc -o bitmessage_icons_rc.py<br />
<br />
== Optional: Compile into a stand-alone EXE ==<br />
# Download [http://www.pyinstaller.org/ PyInstaller].<br />
# Copy Bitmessage's 'src' directory to the PyInstaller directory (which contains pyinstaller.py). <br />
# Run 'pyinstaller.py --onefile --noconsole --icon="src\images\can-icon.ico" src\bitmessagemain.py'<br />
This won't include the OpenSSL DLL file in the EXE; if you send it to someone who doesn't have OpenSSL installed, it will not run. To include the DLL file in the EXE, you must follow these steps:<br />
# After following the steps above, you will see that pyinstaller created a folder called bitmessagemain. In that folder is a file: bitmessagemain.spec. Open it with a text editor.<br />
# Below the line "a.datas," add this line: <code>a.binaries + [('libeay32.dll', 'c:\\windows\\system32\\libeay32.dll', 'BINARY')],</code><br />
# Save and close<br />
# Run this command: pyinstaller.py bitmessagemain/bitmessagemain.spec<br />
<br />
If you do not have the libeay32.dll you can download it here. http://www.dll-files.com/dllindex/dll-files.shtml?libeay32</div>Dokhttps://wiki.bitmessage.org/index.php?title=FAQ&diff=19117FAQ2013-07-04T18:13:25Z<p>Dok: /* How does Bitmessage compare to other messaging methods */</p>
<hr />
<div>==Installation and configuration==<br />
===How do I install Bitmessage===<br />
A great write up for setting up and using Bitmessage on Windows can be found [http://cryptojunky.com/blog/2013/03/09/setting-up-and-using-bitmessage-an-encrypted-communications-platform-based-on-bitcoin/ Here.]<br />
<br />
Bitmessage should run on any OS though it is only lightly tested on OSX. The start-on-boot and minimize-to-tray features are only implemented for Windows thus far. Several examples of how to install Bitmessage on *nix and OSX platforms can be found [https://bitmessage.org/forum/index.php in the forums.]<br />
<br />
===How do I become a node to help the network===<br />
If your connection indicator is green then you are already accepting incoming connections and helping the Bitmessage network.<br />
<br />
If your connection indicator is yellow, check your firewall settings and port forwarding to make sure incoming connections are allowed to your machine on the correct port (Default TCP 8444).<br />
<br />
You can click on the indicator for more information about each color.<br />
<br />
===Why is my Connection Indicator Yellow===<br />
Bitmessage will work normally with a yellow indicator. If your indicator is yellow, you can have up to 8 connections and you are not acting as a relay node for the network. To make your indicator green and act as a relaying node for the Bitmessage network, please forward TCP port 8444 (default).<br />
<br />
===How do I setup Bitmessage to work with Tor===<br />
<br />
'''Tor'''<br />
<br />
If you are using the Tor Browser Bundle skip to the next section. In order for Bitmessage to use Tor as a proxy follow these steps.<br />
*Navigate to Settings > Network Settings and select SOCKS5 from the Type: drop down under the Proxy server / Tor section.<br />
*Next to 'Server hostname:' enter 'localhost' and next to 'Port:' enter '9050'.<br />
*Select ok.<br />
*Restart Bitmessage.<br />
<br />
<br />
'''Tor Browser Bundle'''<br />
*Navigate to Settings > Network Settings and select SOCKS5 from the Type: drop down under the Proxy server / Tor section.<br />
*Next to 'Server hostname:' enter 'localhost' and next to 'Port:' enter '9150'.<br />
*Select ok.<br />
*Restart Bitmessage.<br />
<br />
==Usage==<br />
===How can I run Bitmessage in daemon mode===<br />
Refer to the [[Daemon|Daemon Mode Page]].<br />
<br />
===How many connections should I have===<br />
As long as you have at least one connection, you can communicate with the network. If your connection indicator is yellow, you can have a maximum of 8 connections.<br />
<br />
===Can I send a message to someone that is offline===<br />
Yes. However, if you go offline then they must come back online within 2 days of the message being sent. Nodes delete data, and do not accept data, older than 2 days. <br />
<br />
===How do I format my messages===<br />
Here is [https://qt-project.org/doc/qt-4.8/richtext-html-subset.html the list of supported HTML tags].<br />
<br />
==How does Bitmessage work==<br />
'''Startup'''<br />
<br />
When you first start Bitmessage, your client connects itself to the network and starts downloading a list of known nodes. Each new node that you connect to shares its list of known nodes. In addition to the known nodes, you will also start receiving person-to-person messages, broadcasts, and public keys. If any of these messages are bound for you, they will be shown in your inbox. All of this data is exchanged between all of your connections to make sure that everyone has a copy. <br />
<br />
<br />
'''Sending a Message'''<br />
<br />
When you send a message, your client must first compute a Proof of Work (POW). This POW helps mitigate spam on the network. Nodes and other clients will not process your message if it does not show sufficient POW. After the POW is complete, your message is shared to all of your connections which in turn share it with all of their connections. <br />
<br />
===Where can I find more documentation about Bitmessage===<br />
* [https://bitmessage.org/bitmessage.pdf Overview White Paper (PDF)]<br />
* [[Protocol specification]]<br />
* Detail about the [[Proof of work]]<br />
<br />
==How does Bitmessage compare to other messaging methods==<br />
Here is a table comparing Bitmessage to other common messaging services.<br />
<br />
{| border="1" class="wikitable"<br />
|+ Comparison of Messaging Services<br />
! &nbsp;<br />
! Trustless<br />
! P2P<br />
! Open Source<br />
! Requires Proof of Work<br />
! Hide Sender?<br />
! Hide Receiver?<br />
! Mobile Version<br />
! Application or Web Based<br />
! Text Only Messages<br />
! Attachments<br />
! Acknowledge delivery<br />
|-<br />
! Bitmessage<br />
| Yes<br />
| Yes<br />
| [http://opensource.org/licenses/mit-license.php MIT]<br />
| Yes<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| No<br />
| Small only<br />
| Yes<br />
|-<br />
! Standard Email<br />
| <br />
| No<br />
| Depends<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| No<br />
| Yes<br />
| No<br />
|-<br />
! Email + GPG<br />
| Yes<br />
| No<br />
| Depends<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| Yes<br />
| No<br />
| No<br />
|-<br />
! [https://en.wikipedia.org/wiki/Off-the-Record_Messaging OTR]<br />
| Yes<br />
| No<br />
| GPL V2.1<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/TorChat TorChat]<br />
| Yes<br />
| Yes<br />
| GPL<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
! [http://www.skype.com/en/ Skype]<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| No<br />
| Yes<br />
| <br />
|-<br />
! [http://www.scayl.com/ Scayl]<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Alpha<br />
| Application<br />
| No<br />
| Very Large<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/I2P#E-mail I2P Bote]<br />
| Yes<br />
| Yes<br />
| GPL V3<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
! [https://crypto.cat/ CryptoCat]<br />
| No<br />
| No<br />
| GPL<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/Internet_Relay_Chat IRC]<br />
| <br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! SMS<br />
| <br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| No<br />
| Yes<br />
| No<br />
|-<br />
! [http://retroshare.sourceforge.net/ RetroShare]<br />
| No<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| No<br />
| <br />
| <br />
| <br />
| Yes<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/Freenet#Tools_and_applications Freenet + Frost]<br />
| Yes<br />
| Yes<br />
| GPL<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
! [https://mirror4.freenetproject.org/tools.html Freenet + FMS]<br />
| No<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://mirror4.freenetproject.org/tools.html Freenet + Freemail] 0.2<br />
| No<br />
| Yes<br />
| GPL<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Application<br />
| No<br />
| Yes <br />
| No<br />
|-<br />
! [https://wiki.freenetproject.org/FLIP Freenet + FLIP]<br />
| Yes<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| No<br />
| No<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/TorChat TorChat]<br />
| <br />
| Yes<br />
| <br />
| No<br />
| Via Tor<br />
| Via Tor<br />
| <br />
| Application<br />
| <br />
| Yes<br />
| <br />
|}<br />
<br />
==Troubleshooting==<br />
===My Connection Indicator is Red===<br />
Check your connection settings. Can you access the internet? Have you allowed Bitmessage through your firewall? Have you tried a different port number under Settings > Network Settings? Sometimes Bitmessage takes time to connect to the network. Please allow at least 30 minutes for it to connect before posting to the forum.<br />
<br />
If none of that works, [https://bitmessage.org/forum/index.php please visit the forum here.] <br />
<br />
===I have not received a reply from the Echo Server===<br />
*Your connection indicator should be yellow or green.<br />
*Make sure that your POW is complete and the message has been sent. You should see an acknowledgement under "Status" on the "Sent" tab. <br />
*On average it should take 8 minutes from the time you click the send button to the time you receive a response. <br />
*Be sure to allow extra time in the event that the server is under heavy traffic (Example: An article about Bitmessage was posted on a popular website).<br />
*You can always send a message to another echo server. Here are two echo addresses:<br />
** BM-orkCbppXWSqPpAxnz6jnfTZ2djb5pJKDb<br />
** BM-omXeTjutKWmYgQJjmoZjAG3u3NmaLEdZK<br />
*You may subscribe to the [[Timeservice Broadcast]] to receive network heartbeats.<br />
If you still do not receive a response, [https://bitmessage.org/forum/index.php visit the forum] to see if there is a current technical issue or to submit a new request for assistance.<br />
<br />
===Other===<br />
Here is a list of average times for different parts of Bitmessage. [[PyBitmessage Help]]<br />
<br />
Please [https://bitmessage.org/forum/index.php visit the forum] for all other issues.</div>Dokhttps://wiki.bitmessage.org/index.php?title=API_Reference&diff=19096API Reference2013-07-02T05:11:51Z<p>Dok: /* List of Operations */</p>
<hr />
<div>=== Enable the API ===<br />
To enable the API, the folowing lines have to be inserted into the [[keys.dat]] file:<br />
<pre><br />
apienabled = true<br />
apiport = 8442<br />
apiinterface = 127.0.0.1<br />
apiusername = bradley<br />
apipassword = yourSuperWonderfulPassword98a8#5223345<br />
</pre><br />
Additionally, the user may optionally include an additional entry which will specify a program which Bitmessage will run when certain events occur.<br />
<pre><br />
apinotifypath = c:\\example\\example.exe<br />
</pre><br />
One of these arguments will be passed to your program: startingUp, newMessage, newBroadcast.<br />
programmers should take care, that the application does not crashes when given an unknown command line argument as this list may be expanded.<br />
<br />
=== Remote Access ===<br />
To access the Bitmessage API from a remote location, the apiinterface value has to be changed from '''127.0.0.1''' to '''0.0.0.0'''. In case multiple Network interfaces are available and only one has to be used, its IP address can be specified instead too.<br />
<br />
=== List of Operations ===<br />
Required arguments are denoted inside < and > Optional arguments are inside [ and ]. <br />
{|class="wikitable"<br />
! Command !! Parameters !! Description<br />
|-<br />
| helloWorld || <firstWord> <secondWord> || returns 'firstWord-secondWord'. Used as a simple test of the API.<br />
|-<br />
| add || <integer> <integer> || returns the sum of the integers. Used as a simple test of the API.<br />
|-<br />
| statusBar || <message> || Displays the message in the status bar on the GUI<br />
|-<br />
| listAddresses|| || Lists all addresses shown on the Your Identities tab. Returns a list of objects with these properties:<br />
* label (utf-8)<br />
* address (ascii/utf-8)<br />
* stream (integer)<br />
* enabled (bool)<br />
|-<br />
| createRandomAddress || <label> [eighteenByteRipe] [totalDifficulty] [smallMessageDifficulty] || Creates one address using the random number generator. label should be base64 encoded. eighteenByteRipe is a boolean telling Bitmessage whether to generate an address with an 18 byte RIPE hash(as opposed to a 19 byte hash). This is the same setting as the "Do extra work to make the address 1 or 2 characters shorter" in the user interface. Using False is recommended if you are running some sort of website and will be generating a lot of addresses. Note that even if you don't ask for it, there is still a 1 in 256 chance that you will get an address with an 18 byte RIPE hash so if you actually ''need'' an address with a 19 byte RIPE hash for some reason, you will need to check for it. eighteenByteRipe defaults to False. totalDifficulty and smallMessageDifficulty default to 1.<br />
<br />
Returns the address.<br />
<br />
Warning: At present, Bitmessage gets confused if you use both the API and the UI to make an address at the same time.<br />
|-<br />
|createDeterministicAddresses ||<passphrase> [numberOfAddresses] [addressVersionNumber] [streamNumber] [eighteenByteRipe] [totalDifficulty] [smallMessageDifficulty] || Similar to createRandomAddress except that you may generate many addresses in one go. passphrase should be base64 encoded. numberOfAddresses defaults to 1. addressVersionNumber and streamNumber may be set to 0 which will tell Bitmessage to use the most up-to-date addressVersionNumber and the most available streamNumber. Using zero for each of these fields is recommended. eighteenByteRipe defaults to False. totalDifficulty and smallMessageDifficulty default to 1.<br />
<br />
Returns a list of new addresses. This list will be empty if the addresses already existed.<br />
<br />
Warning: At present, Bitmessage gets confused if you use both the API and the UI to make addresses at the same time.<br />
|-<br />
|getDeterministicAddress ||<passphrase> <addressVersionNumber> <streamNumber> || Similar to createDeterministicAddresses except that the one address that is returned will not be added to the Bitmessage user interface or the keys.dat file. passphrase should be base64 encoded. addressVersionNumber should be set to 3 as this is the only one currently supported. streamNumber must be set to 1 as this is the only one currently supported. <br />
<br />
Returns a single address. <br />
<br />
Warning: At present, Bitmessage gets confused if you use both this API command and the UI to make addresses at the same time.<br />
|-<br />
|<code>getAllInboxMessages</code>|| || Does not include trashed messages. Returns a list of objects with these properties:<br />
* msgid (hex)<br />
* toAddress (ascii/utf-8)<br />
* fromAddress (ascii/utf-8)<br />
* subject (base64, decodes into utf-8)<br />
* message (base64, decodes into utf-8)<br />
* [[Protocol_specification#Message_Encodings|encodingType]] (integer)<br />
* receivedTime (integer, Unix time)<br />
<br />
The msgid is the same as the hash of the message (analogous to the TXID in Bitcoin) thus it is shown in hex as that is the de facto standard. The base64 encoding Bitmessage uses includes line breaks including one on the end of the string.<br />
|-<br />
| getInboxMessageById || - || -<br />
|-<br />
| getSentMessageByAckData || - || -<br />
|-<br />
| getAllSentMessages || - || -<br />
|-<br />
| getSentMessageById || - || -<br />
|-<br />
| trashMessage || <msgid> || returns a simple message saying that the message was trashed assuming it ever even existed. Prior existence is not checked. msgid is encoded in hex just like in the getAllInboxMessages function.<br />
|-<br />
| sendMessage || <toAddress> <fromAddress> <subject> <message> [encodingType] || returns ackdata encoded in hex. subject and message must be encoded in base64 which may optionally include line breaks. If used, the encodingType must be set to 2; this is included for forwards compatibility. <br />
|-<br />
| sendBroadcast || <fromAddress> <subject> <message> [encodingType] || returns ackData encoded in hex. subject and message must be encoded in base64. If used, the encodingType must be set to 2; this is included for forwards compatibility. <br />
|-<br />
| getStatus || <ackData> || returns one of these strings: <strike>notFound, findingPubkey, doingPOW, sentMessage, or ackReceived</strike> notfound, msgqueued, broadcastqueued, broadcastsent, doingpubkeypow, awaitingpubkey, doingmsgpow, forcepow, msgsent, or ackreceived. <br />
|-<br />
| addSubscription|| <address> [label] || Subscribe to an address. label must be base64-encoded.<br />
|-<br />
| deleteSubscription|| <address> || Unsubscribe from an address. The program does not check to see whether you were subscribed in the first place.<br />
|}<br />
<br />
==== Error values ====<br />
<br />
Here are the various error numbers and descriptions you might see.<br />
<br />
{|class="wikitable"<br />
! Error Number!! Message<br />
|- <br />
|0000 || API Error 0000: I need parameters!<br />
|-<br />
| 0001 || API Error 0001: The specified passphrase is blank.<br />
|-<br />
| 0002 || API Error 0002: The address version number currently must be 3 (or 0 which means auto-select).<br />
|- <br />
| 0003 || API Error 0003: The stream number must be 1 (or 0 which means auto-select). Others aren't supported.<br />
|-<br />
| 0004 || API Error 0004: Why would you ask me to generate 0 addresses for you?<br />
|-<br />
| 0005 || API Error 0005: You have (accidentally?) specified too many addresses to make. Maximum 999. This check only exists to prevent mischief; if you really want to create more addresses than this, contact the Bitmessage developers and we can modify the check or you can do it yourself by searching the source code for this message.<br />
|- <br />
| 0006 || API Error 0006: The encoding type must be 2 because that is the only one this program currently supports.<br />
|- <br />
| 0007 || API Error 0007: Could not decode address<br />
|- <br />
| 0008 || API Error 0008: Checksum failed for address<br />
|- <br />
| 0009 || API Error 0009: Invalid characters in address<br />
|-<br />
| 0010 || API Error 0010: Address version number too high (or zero) in address<br />
|-<br />
| 0011 || API Error 0011: The address version number currently must be 2 or 3. Others aren't supported.<br />
|-<br />
| 0012 || API Error 0012: The stream number must be 1. Others aren't supported.<br />
|-<br />
| 0013 || API Error 0013: Could not find your fromAddress in the keys.dat file.<br />
|- <br />
| 0014 || API Error 0014: Your fromAddress is disabled. Cannot send.<br />
|-<br />
| 0015 || API Error 0015: The length of ackData should be 32 bytes (encoded in hex thus 64 characters).<br />
|-<br />
| 0016 || API Error 0016: You are already subscribed to that address.<br />
|-<br />
| 0017 || API Error 0017: Label is not valid UTF-8 data.<br />
|-<br />
| 0018 || API Error 0018: Chan name does not match address.<br />
|}</div>Dokhttps://wiki.bitmessage.org/index.php?title=API_Reference&diff=19095API Reference2013-07-02T05:08:35Z<p>Dok: /* List of Operations */</p>
<hr />
<div>=== Enable the API ===<br />
To enable the API, the folowing lines have to be inserted into the [[keys.dat]] file:<br />
<pre><br />
apienabled = true<br />
apiport = 8442<br />
apiinterface = 127.0.0.1<br />
apiusername = bradley<br />
apipassword = yourSuperWonderfulPassword98a8#5223345<br />
</pre><br />
Additionally, the user may optionally include an additional entry which will specify a program which Bitmessage will run when certain events occur.<br />
<pre><br />
apinotifypath = c:\\example\\example.exe<br />
</pre><br />
One of these arguments will be passed to your program: startingUp, newMessage, newBroadcast.<br />
programmers should take care, that the application does not crashes when given an unknown command line argument as this list may be expanded.<br />
<br />
=== Remote Access ===<br />
To access the Bitmessage API from a remote location, the apiinterface value has to be changed from '''127.0.0.1''' to '''0.0.0.0'''. In case multiple Network interfaces are available and only one has to be used, its IP address can be specified instead too.<br />
<br />
=== List of Operations ===<br />
Required arguments are denoted inside < and > Optional arguments are inside [ and ]. <br />
{|class="wikitable"<br />
! Command !! Parameters !! Description<br />
|-<br />
| helloWorld || <firstWord> <secondWord> || returns 'firstWord-secondWord'. Used as a simple test of the API.<br />
|-<br />
| add || <integer> <integer> || returns the sum of the integers. Used as a simple test of the API.<br />
|-<br />
| statusBar || <message> || Displays the message in the status bar on the GUI<br />
|-<br />
| listAddresses|| || Lists all addresses shown on the Your Identities tab. Returns a list of objects with these properties:<br />
* label (utf-8)<br />
* address (ascii/utf-8)<br />
* stream (integer)<br />
* enabled (bool)<br />
|-<br />
| createRandomAddress || <label> [eighteenByteRipe] [totalDifficulty] [smallMessageDifficulty] || Creates one address using the random number generator. label should be base64 encoded. eighteenByteRipe is a boolean telling Bitmessage whether to generate an address with an 18 byte RIPE hash(as opposed to a 19 byte hash). This is the same setting as the "Do extra work to make the address 1 or 2 characters shorter" in the user interface. Using False is recommended if you are running some sort of website and will be generating a lot of addresses. Note that even if you don't ask for it, there is still a 1 in 256 chance that you will get an address with an 18 byte RIPE hash so if you actually ''need'' an address with a 19 byte RIPE hash for some reason, you will need to check for it. eighteenByteRipe defaults to False. totalDifficulty and smallMessageDifficulty default to 1.<br />
<br />
Returns the address.<br />
<br />
Warning: At present, Bitmessage gets confused if you use both the API and the UI to make an address at the same time.<br />
|-<br />
|createDeterministicAddresses ||<passphrase> [numberOfAddresses] [addressVersionNumber] [streamNumber] [eighteenByteRipe] [totalDifficulty] [smallMessageDifficulty] || Similar to createRandomAddress except that you may generate many addresses in one go. passphrase should be base64 encoded. numberOfAddresses defaults to 1. addressVersionNumber and streamNumber may be set to 0 which will tell Bitmessage to use the most up-to-date addressVersionNumber and the most available streamNumber. Using zero for each of these fields is recommended. eighteenByteRipe defaults to False. totalDifficulty and smallMessageDifficulty default to 1.<br />
<br />
Returns a list of new addresses. This list will be empty if the addresses already existed.<br />
<br />
Warning: At present, Bitmessage gets confused if you use both the API and the UI to make addresses at the same time.<br />
|-<br />
|getDeterministicAddress ||<passphrase> <addressVersionNumber> <streamNumber> || Similar to createDeterministicAddresses except that the one address that is returned will not be added to the Bitmessage user interface or the keys.dat file. passphrase should be base64 encoded. addressVersionNumber should be set to 3 as this is the only one currently supported. streamNumber must be set to 1 as this is the only one currently supported. <br />
<br />
Returns a single address. <br />
<br />
Warning: At present, Bitmessage gets confused if you use both this API command and the UI to make addresses at the same time.<br />
|-<br />
|<code>getAllInboxMessages</code>|| || Does not include trashed messages. Returns a list of objects with these properties:<br />
* msgid (hex)<br />
* toAddress (ascii/utf-8)<br />
* fromAddress (ascii/utf-8)<br />
* subject (base64, decodes into utf-8)<br />
* message (base64, decodes into utf-8)<br />
* [[Protocol_specification#Message_Encodings|encodingType]] (integer)<br />
* receivedTime (integer, Unix time)<br />
<br />
The msgid is the same as the hash of the message (analogous to the TXID in Bitcoin) thus it is shown in hex as that is the de facto standard. The base64 encoding Bitmessage uses includes line breaks including one on the end of the string.<br />
|-<br />
| getInboxMessageById || - || -<br />
|-<br />
| trashMessage || <msgid> || returns a simple message saying that the message was trashed assuming it ever even existed. Prior existence is not checked. msgid is encoded in hex just like in the getAllInboxMessages function.<br />
|-<br />
| sendMessage || <toAddress> <fromAddress> <subject> <message> [encodingType] || returns ackdata encoded in hex. subject and message must be encoded in base64 which may optionally include line breaks. If used, the encodingType must be set to 2; this is included for forwards compatibility. <br />
|-<br />
| sendBroadcast || <fromAddress> <subject> <message> [encodingType] || returns ackData encoded in hex. subject and message must be encoded in base64. If used, the encodingType must be set to 2; this is included for forwards compatibility. <br />
|-<br />
| getStatus || <ackData> || returns one of these strings: <strike>notFound, findingPubkey, doingPOW, sentMessage, or ackReceived</strike> notfound, msgqueued, broadcastqueued, broadcastsent, doingpubkeypow, awaitingpubkey, doingmsgpow, forcepow, msgsent, or ackreceived. <br />
|-<br />
| addSubscription|| <address> [label] || Subscribe to an address. label must be base64-encoded.<br />
|-<br />
| deleteSubscription|| <address> || Unsubscribe from an address. The program does not check to see whether you were subscribed in the first place.<br />
|}<br />
<br />
==== Error values ====<br />
<br />
Here are the various error numbers and descriptions you might see.<br />
<br />
{|class="wikitable"<br />
! Error Number!! Message<br />
|- <br />
|0000 || API Error 0000: I need parameters!<br />
|-<br />
| 0001 || API Error 0001: The specified passphrase is blank.<br />
|-<br />
| 0002 || API Error 0002: The address version number currently must be 3 (or 0 which means auto-select).<br />
|- <br />
| 0003 || API Error 0003: The stream number must be 1 (or 0 which means auto-select). Others aren't supported.<br />
|-<br />
| 0004 || API Error 0004: Why would you ask me to generate 0 addresses for you?<br />
|-<br />
| 0005 || API Error 0005: You have (accidentally?) specified too many addresses to make. Maximum 999. This check only exists to prevent mischief; if you really want to create more addresses than this, contact the Bitmessage developers and we can modify the check or you can do it yourself by searching the source code for this message.<br />
|- <br />
| 0006 || API Error 0006: The encoding type must be 2 because that is the only one this program currently supports.<br />
|- <br />
| 0007 || API Error 0007: Could not decode address<br />
|- <br />
| 0008 || API Error 0008: Checksum failed for address<br />
|- <br />
| 0009 || API Error 0009: Invalid characters in address<br />
|-<br />
| 0010 || API Error 0010: Address version number too high (or zero) in address<br />
|-<br />
| 0011 || API Error 0011: The address version number currently must be 2 or 3. Others aren't supported.<br />
|-<br />
| 0012 || API Error 0012: The stream number must be 1. Others aren't supported.<br />
|-<br />
| 0013 || API Error 0013: Could not find your fromAddress in the keys.dat file.<br />
|- <br />
| 0014 || API Error 0014: Your fromAddress is disabled. Cannot send.<br />
|-<br />
| 0015 || API Error 0015: The length of ackData should be 32 bytes (encoded in hex thus 64 characters).<br />
|-<br />
| 0016 || API Error 0016: You are already subscribed to that address.<br />
|-<br />
| 0017 || API Error 0017: Label is not valid UTF-8 data.<br />
|-<br />
| 0018 || API Error 0018: Chan name does not match address.<br />
|}</div>Dokhttps://wiki.bitmessage.org/index.php?title=Address&diff=19092Address2013-06-30T17:17:17Z<p>Dok: </p>
<hr />
<div>Bitmessage adresses are Base58 encoded public key hashes. An address looks like '''BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash'''.<br />
All Addresses start with '''BM-''', however clients should accept addresses without the prefix. [[PyBitmessage]] does this. The reason behind this idea is the fact, that when double clicking on an address for copy and paste, the prefix is usually not selected due to the dash being a common separator.<br />
<br />
== Public Key usage ==<br />
Addresses may look complicated but they fulfill the purpose of verifying the sender. A Message claiming to be from a specific address can simply be checked by decoding a special field in the data packet with the public key, that represents the address. If the decryption succeeds, the message is from the address it claims to be.<br />
<br />
== Length ==<br />
Without the '''BM-''' prefix, an address is usually 32-34 chars long. Since an address is a hash it can be calculated by the client in a way, that the first bytes are zero (\0) and bitmessage strips these. This causes the client to do much more work to be lucky and find such an address. This is an optional checkbox in [[PyBitmessage]].<br />
<br />
== Address Types ==<br />
There are two address types the user can generate in PyBitmessage. The resulting addresses have no difference, but the method how they are created differs.<br />
<br />
=== Deterministic Address ===<br />
For this type of Address a passphrase is required, that is used to seed the random generator. Using the same passphrase creates the same addresses.<br />
Using deterministic addresses should be done with caution, using a word from a dictionary or a common number can lead to others generating the same address and thus being able to receive messages not intended for them. Generating a deterministic address will not publish the public key. The key is sent in case somebody requests it. This saves [[POW]] time, then generating a bunch of addresses.<br />
<br />
'''Usage'''<br />
* Create the same address on multiple systems without the need of copying [[keys.dat]] or an [[Address Block]].<br />
* create a [[Decentralized Mailing List]].<br />
* Being able to restore the address in case of address database corruption or deletation.<br />
<br />
=== Random Address ===<br />
Random addresses are generated from a randomly chosen number. The resulting address cannot be regenerated without knowledge of the number and therefore the keys.dat should be backed up. Generating random addresses takes slightly longer due to the POW required for the public key broadcast.<br />
<br />
'''Usage'''<br />
* Generate unique addresses<br />
* Generate one time addresses.<br />
<br />
== Recovering/Regenerating/Recreating an Address ==<br />
You can recreate an address in multiple clients without having to move any files between them by using Deterministic Addresses. <br />
<br />
'''Usage'''<br />
* Generate a Deterministic Address and remember all of the selections made when doing so.<br />
* On another Bitmessage client navigate to:<br />
** File > Regenerate deterministic addresses<br />
* Re-enter the data that you used to create the original Deterministic Address<br />
<br />
'''Note:''' Be sure to use a passphrase that is not easy to duplicate. Anyone that use the same passphrase (and other settings) will generate the same address.</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18995Feature request list2013-06-10T02:22:52Z<p>Dok: /* GUI/User Interaction */</p>
<hr />
<div>==GUI/User Interaction==<br />
* Add Multi-language Support (add to site .xml file with language strings )<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
* Mark a read message as unread (In addition to the star/flag/highlight feature that should be added).<br />
<br />
* When you are replying to a message, populate the 'from' field too. It should be the address the message was sent to.<br />
<br />
* Option to automatically add new subscriptions to address book list and/or add option 'Add to Address Book' to context menu in Subscription list<br />
<br />
* 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.<br />
<br />
* <strike>Add 'Cancel' when sending message to clear form fields.</strike> Please check the accepted requests section below before adding requests. <br />
<br />
* 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.<br />
<br />
* Blacklist should also scan the mailinglists to filter out "ostensibly" blacklisted addresses.<br />
<br />
* URI scheme, like "mailto:" See [https://tools.ietf.org/html/rfc6068 RFC 6068] for the mailto reference.<br />
<br />
* 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.<br />
<br />
* The ability to update the client via the GUI.<br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* Allow white-black lists per address (White-listed mailing list without dedicating a client would be one of the uses).<br />
<br />
* 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.<br />
<br />
* 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. <br />
<br />
* Option to use keyfiles when generating either type of address. (or encrypting the keys.dat/etc files in the future)<br />
<br />
* Privately encrypted Broadcast messages. Outlined here: https://bitmessage.org/forum/index.php/topic,1662.0.html<br />
<br />
* Add CPU&Network Usage control.(easy)--[[User:Arthur200000|Arthur200000]] ([[User talk:Arthur200000|talk]]) 23:27, 30 May 2013 (CDT)<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
* Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.<br />
<br />
* Add ability to specify bitmessage address for wiki password recovery/reset<br />
<br />
* Add a ed2k link for faster downloading.(easy)<br />
<br />
* Provide optimized apps([[Wikipedia:SSE|SSE]],etc.)for lower CPU usage and faster working.(easy)<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=API_Reference&diff=18915API Reference2013-06-04T22:42:44Z<p>Dok: /* List of Operations */ Fixed typo with "getDeterministicAddress" (was "...Addresses")</p>
<hr />
<div>=== Enable the API ===<br />
To enable the API, copy and paste these lines into the bitmessagesettings section of the keys.dat file:<br />
<pre><br />
apienabled = true<br />
apiport = 8442<br />
apiinterface = 127.0.0.1<br />
apiusername = bradley<br />
apipassword = yourSuperWonderfulPassword98a8#5223345<br />
</pre><br />
Additionally, you may optionally include an additional entry which will specify a program which Bitmessage will run when certain events occur.<br />
<pre><br />
apinotifypath = c:\\example\\example.exe<br />
</pre><br />
One of these arguments will be passed to your program: startingUp, newMessage, newBroadcast. Be sure your program doesn't crash when given newer arguments introduced in the future as this list will likely expand.<br />
<br />
=== List of Operations ===<br />
Required arguments are denoted inside < and > Optional arguments are inside [ and ]. <br />
{|class="wikitable"<br />
! Command !! Parameters !! Description<br />
|-<br />
| helloWorld || <firstWord> <secondWord> || returns 'firstWord-secondWord'. Used as a simple test of the API.<br />
|-<br />
| add || <integer> <integer> || returns the sum of the integers. Used as a simple test of the API.<br />
|-<br />
| statusBar || <message> || Displays the message in the status bar on the GUI<br />
|-<br />
| listAddresses|| || Lists all addresses shown on the Your Identities tab. Returns a list of objects with these properties:<br />
* label (utf-8)<br />
* address (ascii/utf-8)<br />
* stream (integer)<br />
* enabled (bool)<br />
|-<br />
| createRandomAddress || <label> [eighteenByteRipe] [totalDifficulty] [smallMessageDifficulty] || Creates one address using the random number generator. label should be base64 encoded. eighteenByteRipe is a boolean telling Bitmessage whether to generate an address with an 18 byte RIPE hash(as opposed to a 19 byte hash). This is the same setting as the "Do extra work to make the address 1 or 2 characters shorter" in the user interface. Using False is recommended if you are running some sort of website and will be generating a lot of addresses. Note that even if you don't ask for it, there is still a 1 in 256 chance that you will get an address with an 18 byte RIPE hash so if you actually ''need'' an address with a 19 byte RIPE hash for some reason, you will need to check for it. eighteenByteRipe defaults to False. totalDifficulty and smallMessageDifficulty default to 1.<br />
<br />
Returns the address.<br />
<br />
Warning: At present, Bitmessage gets confused if you use both the API and the UI to make an address at the same time.<br />
|-<br />
|createDeterministicAddresses ||<passphrase> [numberOfAddresses] [addressVersionNumber] [streamNumber] [eighteenByteRipe] [totalDifficulty] [smallMessageDifficulty] || Similar to createRandomAddress except that you may generate many addresses in one go. passphrase should be base64 encoded. numberOfAddresses defaults to 1. addressVersionNumber and streamNumber may be set to 0 which will tell Bitmessage to use the most up-to-date addressVersionNumber and the most available streamNumber. Using zero for each of these fields is recommended. eighteenByteRipe defaults to False. totalDifficulty and smallMessageDifficulty default to 1.<br />
<br />
Returns a list of new addresses. This list will be empty if the addresses already existed.<br />
<br />
Warning: At present, Bitmessage gets confused if you use both the API and the UI to make addresses at the same time.<br />
|-<br />
|getDeterministicAddress ||<passphrase> <addressVersionNumber> <streamNumber> || Similar to createDeterministicAddresses except that the one address that is returned will not be added to the Bitmessage user interface or the keys.dat file. passphrase should be base64 encoded. addressVersionNumber should be set to 3 as this is the only one currently supported. streamNumber must be set to 1 as this is the only one currently supported. <br />
<br />
Returns a single address. <br />
<br />
Warning: At present, Bitmessage gets confused if you use both this API command and the UI to make addresses at the same time.<br />
|-<br />
|<code>getAllInboxMessages</code>|| || Does not include trashed messages. Returns a list of objects with these properties:<br />
* msgid (hex)<br />
* toAddress (ascii/utf-8)<br />
* fromAddress (ascii/utf-8)<br />
* subject (base64, decodes into utf-8)<br />
* message (base64, decodes into utf-8)<br />
* [[Protocol_specification#Message_Encodings|encodingType]] (integer)<br />
* receivedTime (integer, Unix time)<br />
<br />
The msgid is the same as the hash of the message (analogous to the TXID in Bitcoin) thus it is shown in hex as that is the de facto standard. The base64 encoding Bitmessage uses includes line breaks including one on the end of the string. The [[Protocol_specification#Message_Encodings|encodingType]] property is currently always set to 2 because, unfortunately, the inbox table in Bitmessage does not record the encoding type. In the future Bitmessage will record it and at that time this field will be accurate therefore the field is included here to maintain forwards compatibility.<br />
|-<br />
| trashMessage || <msgid> || returns a simple message saying that the message was trashed assuming it ever even existed. Prior existence is not checked. msgid is encoded in hex just like in the getAllInboxMessages function.<br />
|-<br />
| sendMessage || <toAddress> <fromAddress> <subject> <message> [encodingType] || returns ackdata encoded in hex. subject and message must be encoded in base64 which may optionally include line breaks. If used, the encodingType must be set to 2; this is included for forwards compatibility. <br />
|-<br />
| sendBroadcast || <fromAddress> <subject> <message> [encodingType] || returns ackData encoded in hex. subject and message must be encoded in base64. If used, the encodingType must be set to 2; this is included for forwards compatibility. <br />
|-<br />
| getStatus || <ackData> || returns one of these strings: <strike>notFound, findingPubkey, doingPOW, sentMessage, or ackReceived</strike> notfound, msgqueued, broadcastqueued, broadcastsent, doingpubkeypow, awaitingpubkey, doingmsgpow, msgsent, or ackreceived. <br />
|-<br />
| addSubscription|| <address> [label] || Subscribe to an address. label must be base64-encoded.<br />
|-<br />
| deleteSubscription|| <address> || Unsubscribe from an address. The program does not check to see whether you were subscribed in the first place.<br />
|}<br />
<br />
==== Here are the various error numbers and descriptions you might see. ====<br />
<br />
{|class="wikitable"<br />
! Error Number!! Message<br />
|- <br />
|0000 || API Error 0000: I need parameters!<br />
|-<br />
| 0001 || API Error 0001: The specified passphrase is blank.<br />
|-<br />
| 0002 || API Error 0002: The address version number currently must be 3 (or 0 which means auto-select).<br />
|- <br />
| 0003 || API Error 0003: The stream number must be 1 (or 0 which means auto-select). Others aren't supported.<br />
|-<br />
| 0004 || API Error 0004: Why would you ask me to generate 0 addresses for you?<br />
|-<br />
| 0005 || API Error 0005: You have (accidentally?) specified too many addresses to make. Maximum 999. This check only exists to prevent mischief; if you really want to create more addresses than this, contact the Bitmessage developers and we can modify the check or you can do it yourself by searching the source code for this message.<br />
|- <br />
| 0006 || API Error 0006: The encoding type must be 2 because that is the only one this program currently supports.<br />
|- <br />
| 0007 || API Error 0007: Could not decode address<br />
|- <br />
| 0008 || API Error 0008: Checksum failed for address<br />
|- <br />
| 0009 || API Error 0009: Invalid characters in address<br />
|-<br />
| 0010 || API Error 0010: Address version number too high (or zero) in address<br />
|-<br />
| 0011 || API Error 0011: The address version number currently must be 2 or 3. Others aren't supported.<br />
|-<br />
| 0012 || API Error 0012: The stream number must be 1. Others aren't supported.<br />
|-<br />
| 0013 || API Error 0013: Could not find your fromAddress in the keys.dat file.<br />
|- <br />
| 0014 || API Error 0014: Your fromAddress is disabled. Cannot send.<br />
|-<br />
| 0015 || API Error 0015: The length of ackData should be 32 bytes (encoded in hex thus 64 characters).<br />
|-<br />
| 0016 || API Error 0016: You are already subscribed to that address.<br />
|-<br />
| 0017 || API Error 0017: Label is not valid UTF-8 data.<br />
|}</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18912Feature request list2013-06-04T16:34:53Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* Add Multi-language Support (add to site .xml file with language strings )<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
* Mark a read message as unread (In addition to the star/flag/highlight feature that should be added).<br />
<br />
* When you are replying to a message, populate the 'from' field too. It should be the address the message was sent to.<br />
<br />
* Option to automatically add new subscriptions to address book list and/or add option 'Add to Address Book' to context menu in Subscription list<br />
<br />
* 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.<br />
<br />
* <strike>Add 'Cancel' when sending message to clear form fields.</strike> Please check the accepted requests section below before adding requests. <br />
<br />
* 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.<br />
<br />
* Blacklist should also scan the mailinglists to filter out "ostensibly" blacklisted addresses.<br />
<br />
* URI scheme, like "mailto:" See [https://tools.ietf.org/html/rfc6068 RFC 6068] for the mailto reference.<br />
<br />
* 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.<br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* Allow white-black lists per address (White-listed mailing list without dedicating a client would be one of the uses).<br />
<br />
* 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.<br />
<br />
* 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. <br />
<br />
* Option to use keyfiles when generating either type of address. (or encrypting the keys.dat/etc files in the future)<br />
<br />
* Privately encrypted Broadcast messages. Outlined here: https://bitmessage.org/forum/index.php/topic,1662.0.html<br />
<br />
* Add CPU&Network Usage control.(easy)--[[User:Arthur200000|Arthur200000]] ([[User talk:Arthur200000|talk]]) 23:27, 30 May 2013 (CDT)<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
* Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.<br />
<br />
* Add ability to specify bitmessage address for wiki password recovery/reset<br />
<br />
* Add a ed2k link for faster downloading.(easy)<br />
<br />
* Provide optimized apps([[Wikipedia:SSE|SSE]],etc.)for lower CPU usage and faster working.(easy)<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18883Feature request list2013-05-29T16:21:19Z<p>Dok: /* GUI/User Interaction */</p>
<hr />
<div>==GUI/User Interaction==<br />
* Add Multi-language Support (add to site .xml file with language strings )<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
* Mark a read message as unread (In addition to the star/flag/highlight feature that should be added).<br />
<br />
* When you are replying to a message, populate the 'from' field too. It should be the address the message was sent to.<br />
<br />
* Option to automatically add new subscriptions to address book list and/or add option 'Add to Address Book' to context menu in Subscription list<br />
<br />
* 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.<br />
<br />
* <strike>Add 'Cancel' when sending message to clear form fields.</strike> Please check the accepted requests section below before adding requests. <br />
<br />
* 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.<br />
<br />
* Blacklist should also scan the mailinglists to filter out "ostensibly" blacklisted addresses.<br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* Allow white-black lists per address (White-listed mailing list without dedicating a client would be one of the uses).<br />
<br />
* 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.<br />
<br />
* 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. <br />
<br />
* Option to use keyfiles when generating either type of address. (or encrypting the keys.dat/etc files in the future)<br />
<br />
* Privately encrypted Broadcast messages. Outlined here: https://bitmessage.org/forum/index.php/topic,1662.0.html<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
* Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.<br />
<br />
* Add ability to specify bitmessage address for wiki password recovery/reset<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Daemon&diff=18882Daemon2013-05-29T16:14:09Z<p>Dok: </p>
<hr />
<div>PyBitmessage can be run in deamon mode by adding this line to your keys.dat file under [bitmessagesettings]:<br />
<br />
daemon = true<br />
<br />
In this mode, PyBitmessage doesn't require Qt. You will then need the [https://bitmessage.org/wiki/API_Reference API]. If you do not yet have a keys.dat file because you have not yet run Bitmessage, run it. It will create the keys.dat file for you then exit if it cannot find PyQt.<br />
<br />
Here is an example Daemon for using Bitmessage via a console: [https://github.com/Dokument/PyBitmessage-Daemon Bitmessage Daemon]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18865Feature request list2013-05-26T01:51:06Z<p>Dok: /* GUI/User Interaction */</p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
* Mark a read message as unread (In addition to the star/flag/highlight feature that should be added).<br />
<br />
* When you are replying to a message, populate the 'from' field too. It should be the address the message was sent to.<br />
<br />
* Option to automatically add new subscriptions to address book list and/or add option 'Add to Address Book' to context menu in Subscription list<br />
<br />
* 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.<br />
<br />
* <strike>Add 'Cancel' when sending message to clear form fields.</strike> Please check the accepted requests section below before adding requests. <br />
<br />
* 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.<br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* Allow white-black lists per address (White-listed mailing list without dedicating a client would be one of the uses).<br />
<br />
* 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.<br />
<br />
* 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. <br />
<br />
* Option to use keyfiles when generating either type of address. (or encrypting the keys.dat/etc files in the future)<br />
<br />
* Privately encrypted Broadcast messages. Outlined here: https://bitmessage.org/forum/index.php/topic,1662.0.html<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
* Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.<br />
<br />
* Add ability to specify bitmessage address for wiki password recovery/reset<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18846Feature request list2013-05-24T21:30:43Z<p>Dok: /* Backend */</p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
* Mark a read message as unread (In addition to the star/flag/highlight feature that should be added).<br />
<br />
* When you are replying to a message, populate the 'from' field too. It should be the address the message was sent to.<br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* Allow white-black lists per address (White-listed mailing list without dedicating a client would be one of the uses).<br />
<br />
* 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.<br />
<br />
* 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. <br />
<br />
* Option to use keyfiles when generating either type of address. (or encrypting the keys.dat/etc files in the future)<br />
<br />
* Privately encrypted Broadcast messages. Outlined here: https://bitmessage.org/forum/index.php/topic,1662.0.html<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
* Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18839Feature request list2013-05-22T19:04:41Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
* Mark a read message as unread (In addition to the star/flag/highlight feature that should be added).<br />
<br />
* When you are replying to a message, populate the 'from' field too. It should be the address the message was sent to.<br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* Allow white-black lists per address (White-listed mailing list without dedicating a client would be one of the uses).<br />
<br />
* 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.<br />
<br />
* 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. <br />
<br />
* Option to use keyfiles when generating either type of address. (or encrypting the keys.dat/etc files in the future)<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
* Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18836Feature request list2013-05-20T18:06:33Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
* Mark a read message as unread (In addition to the star/flag/highlight feature that should be added).<br />
<br />
* When you are replying to a message, populate the 'from' field too. It should be the address the message was sent to.<br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* Allow white-black lists per address (White-listed mailing list without dedicating a client would be one of the uses).<br />
<br />
* 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.<br />
<br />
* 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. <br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
* Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=FAQ&diff=18821FAQ2013-05-17T12:49:58Z<p>Dok: /* Other */</p>
<hr />
<div>==Installation and configuration==<br />
===How do I install Bitmessage===<br />
A great write up for setting up and using Bitmessage on Windows can be found [http://cryptojunky.com/blog/2013/03/09/setting-up-and-using-bitmessage-an-encrypted-communications-platform-based-on-bitcoin/ Here.]<br />
<br />
Bitmessage should run on any OS though it is only lightly tested on OSX. The start-on-boot and minimize-to-tray features are only implemented for Windows thus far. Several examples of how to install Bitmessage on *nix and OSX platforms can be found [https://bitmessage.org/forum/index.php in the forums.]<br />
<br />
===How do I become a node to help the network===<br />
If your connection indicator is green then you are already accepting incoming connections and helping the Bitmessage network.<br />
<br />
If your connection indicator is yellow, check your firewall settings and port forwarding to make sure incoming connections are allowed to your machine on the correct port (Default TCP 8444).<br />
<br />
You can click on the indicator for more information about each color.<br />
<br />
===Why is my Connection Indicator Yellow===<br />
Bitmessage will work normally with a yellow indicator. If your indicator is yellow, you can have up to 8 connections and you are not acting as a relay node for the network. To make your indicator green and act as a relaying node for the Bitmessage network, please forward TCP port 8444 (default).<br />
<br />
===How do I setup Bitessage to work with Tor===<br />
<br />
'''Tor'''<br />
<br />
If you are using the Tor Browser Bundle skip to the next section. In order for Bitmessage to use Tor as a proxy follow these steps.<br />
*Navigate to Settings > Network Settings and select SOCKS5 from the Type: drop down under the Proxy server / Tor section.<br />
*Next to 'Server hostname:' enter 'localhost' and next to 'Port:' enter '9050'.<br />
*Select ok.<br />
*Restart Bitmessage.<br />
<br />
<br />
'''Tor Browser Bundle'''<br />
*Navigate to Settings > Network Settings and select SOCKS5 from the Type: drop down under the Proxy server / Tor section.<br />
*Next to 'Server hostname:' enter 'localhost' and next to 'Port:' enter '9150'.<br />
*Select ok.<br />
*Restart Bitmessage.<br />
<br />
==Usage==<br />
===How can I run Bitmessage in daemon mode===<br />
Refer to the [https://bitmessage.org/wiki/Daemon Daemon Mode Page Here.]<br />
<br />
===How many connections should I have===<br />
As long as you have at least one connection, you can communicate with the network. If your connection indicator is yellow, you can have a maximum of 8 connections.<br />
<br />
===Can I send a message to someone that is offline===<br />
Yes. However, if you go offline then they must come back online within 2 days of the message being sent. Nodes delete data, and do not accept data, older than 2 days. <br />
<br />
===How do I format my messages===<br />
Here is the list of supported HTML tags. [hhttps://qt-project.org/doc/qt-4.8/richtext-html-subset.html https://qt-project.org/doc/qt-4.8/richtext-html-subset.html]<br />
<br />
==How does Bitmessage work==<br />
'''Startup'''<br />
<br />
When you first start Bitmessage, your client connects itself to the network and starts downloading a list of known nodes. Each new node that you connect to shares its list of known nodes. In addition to the known nodes, you will also start receiving person-to-person messages, broadcasts, and public keys. If any of these messages are bound for you, they will be shown in your inbox. All of this data is exchanged between all of your connections to make sure that everyone has a copy. <br />
<br />
<br />
'''Sending a Message'''<br />
<br />
When you send a message, your client must first compute a Proof of Work (POW). This POW helps mitigate spam on the network. Nodes and other clients will not process your message if it does not show sufficient POW. After the POW is complete, your message is shared to all of your connections which in turn share it with all of their connections. <br />
<br />
===Where can I find more documentation about Bitmessage===<br />
* [https://bitmessage.org/bitmessage.pdf Overview White Paper (PDF)]<br />
* [https://bitmessage.org/wiki/Protocol_specification Protocol Specification]<br />
* [https://bitmessage.org/wiki/Proof_of_work Detail about the Proof of Work]<br />
<br />
==How does Bitmessage compare to other messaging methods==<br />
Here is a table comparing Bitmessage to other common messaging services.<br />
<br />
{| border="1" class="wikitable"<br />
|+ Comparison of Messaging Services<br />
! &nbsp;<br />
! Trustless<br />
! P2P<br />
! Open Source<br />
! Requires Proof of Work<br />
! Hide Sender?<br />
! Hide Receiver?<br />
! Mobile Version<br />
! Application or Web Based<br />
! Text Only Messages<br />
! Attachments<br />
! Acknowledge delivery<br />
|-<br />
! Bitmessage<br />
| Yes<br />
| Yes<br />
| [http://opensource.org/licenses/mit-license.php MIT]<br />
| Yes<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| No<br />
| Small only<br />
| Yes<br />
|-<br />
! Standard Email<br />
| <br />
| No<br />
| Depends<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| No<br />
| Yes<br />
| No<br />
|-<br />
! Email + GPG<br />
| Yes<br />
| No<br />
| Depends<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| Yes<br />
| No<br />
| No<br />
|-<br />
! [https://en.wikipedia.org/wiki/Off-the-Record_Messaging OTR]<br />
| Yes<br />
| No<br />
| GPL V2.1<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/TorChat TorChat]<br />
| Yes<br />
| Yes<br />
| GPL<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
! [http://www.skype.com/en/ Skype]<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| No<br />
| Yes<br />
| <br />
|-<br />
! [http://www.scayl.com/ Scayl]<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Alpha<br />
| Application<br />
| No<br />
| Very Large<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/I2P#E-mail I2P Bote]<br />
| Yes<br />
| Yes<br />
| GPL V3<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
! [https://crypto.cat/ CryptoCat]<br />
| No<br />
| No<br />
| GPL<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/Internet_Relay_Chat IRC]<br />
| <br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! SMS<br />
| <br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| No<br />
| Yes<br />
| No<br />
|-<br />
! [http://retroshare.sourceforge.net/ RetroShare]<br />
| No<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| No<br />
| <br />
| <br />
| <br />
| Yes<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/Freenet#Tools_and_applications Freenet + Frost]<br />
| Yes<br />
| Yes<br />
| GPL<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
! [https://mirror4.freenetproject.org/tools.html Freenet + FMS]<br />
| No<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://mirror4.freenetproject.org/tools.html Freenet + Freemail] 0.2<br />
| No<br />
| Yes<br />
| GPL<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Application<br />
| No<br />
| Yes <br />
| No<br />
|-<br />
! [https://wiki.freenetproject.org/FLIP Freenet + FLIP]<br />
| Yes<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| No<br />
| No<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|}<br />
<br />
==Troubleshooting==<br />
===My Connection Indicator is Red===<br />
Check your connection settings. Can you access the internet? Have you allowed Bitmessage through your firewall? Have you tried a different port number under Settings > Network Settings? Sometimes Bitmessage takes time to connect to the network. Please allow at least 30 minutes for it to connect before posting to the forum.<br />
<br />
If none of that works, [https://bitmessage.org/forum/index.php please visit the forum here.] <br />
<br />
===I have not received a reply from the Echo Server===<br />
*Your connection indicator should be yellow or green.<br />
*Make sure that your POW is complete and the message has been sent. You should see an acknowledgement under "Status" on the "Sent" tab. <br />
*On average it should take 8 minutes from the time you click the send button to the time you receive a response. <br />
*Be sure to allow extra time in the event that the server is under heavy traffic (Example: An article about Bitmessage was posted on a popular website).<br />
*You can always send a message to another echo server. Here are two echo addresses:<br />
** BM-orkCbppXWSqPpAxnz6jnfTZ2djb5pJKDb<br />
** BM-omXeTjutKWmYgQJjmoZjAG3u3NmaLEdZK<br />
<br />
If you still do not receive a response, [https://bitmessage.org/forum/index.php visit the forum] to see if there is a current technical issue or to submit a new request for assistance.<br />
<br />
===Other===<br />
Here is a list of average times for different parts of Bitmessage. https://bitmessage.org/wiki/PyBitmessage_Help<br />
<br />
Please [https://bitmessage.org/forum/index.php visit the forum] for all other issues.</div>Dokhttps://wiki.bitmessage.org/index.php?title=Compiling_instructions&diff=18820Compiling instructions2013-05-17T09:27:11Z<p>Dok: /* Optional: Compile into a stand-alone EXE */</p>
<hr />
<div>This page should help novice users run Bitmessage from the source code files.<br />
<br />
= Linux =<br />
== Ubuntu ==<br />
There's an unofficial Personal Package Archive for Pybitmessage which provides an easy way to get Pybitmessage. To install it, open a [https://help.ubuntu.com/community/UsingTheTerminal#Starting_a_Terminal Terminal] (press Ctrl+Alt+T) and enter the following:<br />
sudo add-apt-repository -y ppa:fuzzgun/pybitmessage && sudo apt-get update<br />
sudo apt-get install pybitmessage<br />
<br />
== From source ==<br />
<small>''Note for Fedora users: Fedora does not currently compile EC into OpenSSL and thus will not work. A workaround is needed to either recompile OpenSSL, or locate/install a OpenSSL package that supports EC extensions.''</small><br />
<br />
<small>''Note for Debian Wheezy (6.0) users: Debian Wheezy does not offer packages (like Python, OpenSSL) in versions that are needed for Bitmessage. You can still try to [https://github.com/Bitmessage/PyBitmessage/issues/47#issuecomment-17774377 work around these problems].''</small><br />
<br />
; Install dependencies:<br />
: APT-based distributions (Debian, Ubuntu): <code>sudo apt-get install python openssl git python-qt4</code><br />
: RPM-based distributions (Red Hat, Fedora): <code>sudo yum install python openssl git</code><br />
<br />
; Download and run Bitmessage:<br />
git clone <nowiki>https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage</nowiki><br />
cd $HOME/PyBitmessage/src/ && python bitmessagemain.py<br />
<br />
= Windows =<br />
# Download and install the latest revision of Python 2.7 (currently Python 2.7.3 from [http://www.python.org/download/releases/2.7.3/ here]). The ''Windows x86 MSI Installer'' is the right choice for most people. (64-bit users may want the 64-bit version).<br />
# Test that it installed:<br />
## Open a command prompt by going to Start > Run. Type 'cmd' then press enter.<br />
## type 'python'. If python is installed, you should see the python version and the prompt: '>>>'<br />
## If you see a message such as: "'Python is not recognized as an internal or external command..." then you must add the python path to your path environmental variable:<br />
### Find the location where Python was installed (in particular, the location where python.exe exists). It might simply be in c:\Python2.7 <br />
### Follow [http://www.computerhope.com/issues/ch000549.htm these directions] to add the Python path to your path variable.<br />
### Close the command prompt window and reopen it. <br />
### Try running 'python' again.<br />
##Press Ctrl-Z to exit Python.<br />
# Bitmessage has two dependencies. The first is PyQt. Download and install PyQt from [http://www.riverbankcomputing.com/software/pyqt/download here]. You will want the Binary Package since it is already compiled for you. Be sure to select the version for Python 2.7. It is labeled as Py2.7. <br />
# The second dependency is OpenSSL which you can download from [http://slproweb.com/products/Win32OpenSSL.html here]. There you will also notice the link to download the Visual C++ 2008 program in case you also find that you need that as well. (The OpenSSL installer will complain if you need to install the Visual C++ Redistributable.)<br />
# Download the source code for PyBitmessage from GitHub. If it is in a zip file, you will need to extract it. There should be a few files and a few folders where one of the folders is 'src'. <br />
# To run Bitmessage, navigate into the 'src' folder and then double click on the bitmessagemain.py file, or in a command prompt, change directories to the 'src' directory which holds bitmessagemain.py and type 'python bitmessagemain.py'. <br />
<br />
== If you change user interface files ==<br />
You can use Qt's Designer application to modify the user interface. After you do this, you will need to 'compile' .ui files into .py files. <br />
# In a command prompt, change directories to the directory of your .ui file.<br />
# Run 'pyuic4 example.ui > example.py' If you get a message similar to 'pyuic4 is not recognized as an internal or external command' then you must add the PyQt directory to your system's path variable. This directory should hold pyuic4.bat. It might be in C:\Python27\Lib\site-packages\PyQt4. Remember to close the command window and reopen it after you change your path variable.<br />
<br />
If you add icons to bitmessage_icons.qrc, then you must run this command:<br />
pyrcc4 bitmessage_icons.qrc -o bitmessage_icons_rc.py<br />
<br />
== Optional: Compile into a stand-alone EXE ==<br />
# Download [http://www.pyinstaller.org/ PyInstaller].<br />
# Copy all of the source code files from the 'src' directory to the PyInstaller directory (which contains pyinstaller.py). <br />
# Run 'pyinstaller.py --onefile --noconsole --icon="images\can-icon.ico" bitmessagemain.py'<br />
This won't include the OpenSSL DLL file in the EXE; if you send it to someone who doesn't have OpenSSL installed, it will not run. To include the DLL file in the EXE, you must follow these steps:<br />
# After following the steps above, you will see that pyinstaller created a folder called bitmessagemain. In that folder is a file: bitmessagemain.spec. Open it with a text editor.<br />
# Below the line "a.datas," add this line: <code>a.binaries + [('libeay32.dll', 'c:\\windows\\system32\\libeay32.dll', 'BINARY')],</code><br />
# Save and close<br />
# Run this command: pyinstaller.py bitmessagemain/bitmessagemain.spec<br />
<br />
If you do not have the libeay32.dll you can download it here. http://www.dll-files.com/dllindex/dll-files.shtml?libeay32</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18819Feature request list2013-05-17T09:07:46Z<p>Dok: /* GUI/User Interaction */</p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
* Mark a read message as unread (In addition to the star/flag/highlight feature that should be added).<br />
<br />
* When you are replying to a message, populate the 'from' field too. It should be the address the message was sent to.<br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* Allow white-black lists per address (White-listed mailing list without dedicating a client would be one of the uses).<br />
<br />
* 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.<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
* Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18818Feature request list2013-05-17T07:30:13Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
* Mark a read message as unread (In addition to the star/flag/highlight feature that should be added).<br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* Allow white-black lists per address (White-listed mailing list without dedicating a client would be one of the uses).<br />
<br />
* 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.<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
* Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18814Feature request list2013-05-16T21:07:51Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
* Mark a read message as unread (In addition to the star/flag/highlight feature that should be added).<br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* Allow white-black lists per address (White-listed mailing list without dedicating a client would be one of the uses).<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
* Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18808Feature request list2013-05-15T17:32:13Z<p>Dok: /* Backend */</p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* Allow white-black lists per address (White-listed mailing list without dedicating a client would be one of the uses).<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
* Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18807Feature request list2013-05-15T17:30:26Z<p>Dok: /* Wiki/Forum */</p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
* Package in a compressed format (zip,7z,tar.gz,etc) and include the Bitmessage version in the container name.<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18806Feature request list2013-05-15T17:28:40Z<p>Dok: /* Accepted Requests (Implemented in version 0.3.0 and before) */</p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* <strike>Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=FAQ&diff=18805FAQ2013-05-15T17:10:39Z<p>Dok: /* How does Bitmessage compare to other messaging methods */</p>
<hr />
<div>==Installation and configuration==<br />
===How do I install Bitmessage===<br />
A great write up for setting up and using Bitmessage on Windows can be found [http://cryptojunky.com/blog/2013/03/09/setting-up-and-using-bitmessage-an-encrypted-communications-platform-based-on-bitcoin/ Here.]<br />
<br />
Bitmessage should run on any OS though it is only lightly tested on OSX. The start-on-boot and minimize-to-tray features are only implemented for Windows thus far. Several examples of how to install Bitmessage on *nix and OSX platforms can be found [https://bitmessage.org/forum/index.php in the forums.]<br />
<br />
===How do I become a node to help the network===<br />
If your connection indicator is green then you are already accepting incoming connections and helping the Bitmessage network.<br />
<br />
If your connection indicator is yellow, check your firewall settings and port forwarding to make sure incoming connections are allowed to your machine on the correct port (Default TCP 8444).<br />
<br />
You can click on the indicator for more information about each color.<br />
<br />
===Why is my Connection Indicator Yellow===<br />
Bitmessage will work normally with a yellow indicator. If your indicator is yellow, you can have up to 8 connections and you are not acting as a relay node for the network. To make your indicator green and act as a relaying node for the Bitmessage network, please forward TCP port 8444 (default).<br />
<br />
===How do I setup Bitessage to work with Tor===<br />
<br />
'''Tor'''<br />
<br />
If you are using the Tor Browser Bundle skip to the next section. In order for Bitmessage to use Tor as a proxy follow these steps.<br />
*Navigate to Settings > Network Settings and select SOCKS5 from the Type: drop down under the Proxy server / Tor section.<br />
*Next to 'Server hostname:' enter 'localhost' and next to 'Port:' enter '9050'.<br />
*Select ok.<br />
*Restart Bitmessage.<br />
<br />
<br />
'''Tor Browser Bundle'''<br />
*Navigate to Settings > Network Settings and select SOCKS5 from the Type: drop down under the Proxy server / Tor section.<br />
*Next to 'Server hostname:' enter 'localhost' and next to 'Port:' enter '9150'.<br />
*Select ok.<br />
*Restart Bitmessage.<br />
<br />
==Usage==<br />
===How can I run Bitmessage in daemon mode===<br />
Refer to the [https://bitmessage.org/wiki/Daemon Daemon Mode Page Here.]<br />
<br />
===How many connections should I have===<br />
As long as you have at least one connection, you can communicate with the network. If your connection indicator is yellow, you can have a maximum of 8 connections.<br />
<br />
===Can I send a message to someone that is offline===<br />
Yes. However, if you go offline then they must come back online within 2 days of the message being sent. Nodes delete data, and do not accept data, older than 2 days. <br />
<br />
===How do I format my messages===<br />
Here is the list of supported HTML tags. [hhttps://qt-project.org/doc/qt-4.8/richtext-html-subset.html https://qt-project.org/doc/qt-4.8/richtext-html-subset.html]<br />
<br />
==How does Bitmessage work==<br />
'''Startup'''<br />
<br />
When you first start Bitmessage, your client connects itself to the network and starts downloading a list of known nodes. Each new node that you connect to shares its list of known nodes. In addition to the known nodes, you will also start receiving person-to-person messages, broadcasts, and public keys. If any of these messages are bound for you, they will be shown in your inbox. All of this data is exchanged between all of your connections to make sure that everyone has a copy. <br />
<br />
<br />
'''Sending a Message'''<br />
<br />
When you send a message, your client must first compute a Proof of Work (POW). This POW helps mitigate spam on the network. Nodes and other clients will not process your message if it does not show sufficient POW. After the POW is complete, your message is shared to all of your connections which in turn share it with all of their connections. <br />
<br />
===Where can I find more documentation about Bitmessage===<br />
* [https://bitmessage.org/bitmessage.pdf Overview White Paper (PDF)]<br />
* [https://bitmessage.org/wiki/Protocol_specification Protocol Specification]<br />
* [https://bitmessage.org/wiki/Proof_of_work Detail about the Proof of Work]<br />
<br />
==How does Bitmessage compare to other messaging methods==<br />
Here is a table comparing Bitmessage to other common messaging services.<br />
<br />
{| border="1" class="wikitable"<br />
|+ Comparison of Messaging Services<br />
! &nbsp;<br />
! Trustless<br />
! P2P<br />
! Open Source<br />
! Requires Proof of Work<br />
! Hide Sender?<br />
! Hide Receiver?<br />
! Mobile Version<br />
! Application or Web Based<br />
! Text Only Messages<br />
! Attachments<br />
! Acknowledge delivery<br />
|-<br />
! Bitmessage<br />
| Yes<br />
| Yes<br />
| [http://opensource.org/licenses/mit-license.php MIT]<br />
| Yes<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| No<br />
| Small only<br />
| Yes<br />
|-<br />
! Standard Email<br />
| <br />
| No<br />
| Depends<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| No<br />
| Yes<br />
| No<br />
|-<br />
! Email + GPG<br />
| Yes<br />
| No<br />
| Depends<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| Yes<br />
| No<br />
| No<br />
|-<br />
! [https://en.wikipedia.org/wiki/Off-the-Record_Messaging OTR]<br />
| Yes<br />
| No<br />
| GPL V2.1<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/TorChat TorChat]<br />
| Yes<br />
| Yes<br />
| GPL<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
! [http://www.skype.com/en/ Skype]<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| No<br />
| Yes<br />
| <br />
|-<br />
! [http://www.scayl.com/ Scayl]<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Alpha<br />
| Application<br />
| No<br />
| Very Large<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/I2P#E-mail I2P Bote]<br />
| Yes<br />
| Yes<br />
| GPL V3<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
! [https://crypto.cat/ CryptoCat]<br />
| No<br />
| No<br />
| GPL<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/Internet_Relay_Chat IRC]<br />
| <br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! SMS<br />
| <br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| No<br />
| Yes<br />
| No<br />
|-<br />
! [http://retroshare.sourceforge.net/ RetroShare]<br />
| No<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| No<br />
| <br />
| <br />
| <br />
| Yes<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/Freenet#Tools_and_applications Freenet + Frost]<br />
| Yes<br />
| Yes<br />
| GPL<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
! [https://mirror4.freenetproject.org/tools.html Freenet + FMS]<br />
| No<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://mirror4.freenetproject.org/tools.html Freenet + Freemail] 0.2<br />
| No<br />
| Yes<br />
| GPL<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Application<br />
| No<br />
| Yes <br />
| No<br />
|-<br />
! [https://wiki.freenetproject.org/FLIP Freenet + FLIP]<br />
| Yes<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| No<br />
| No<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|}<br />
<br />
==Troubleshooting==<br />
===My Connection Indicator is Red===<br />
Check your connection settings. Can you access the internet? Have you allowed Bitmessage through your firewall? Have you tried a different port number under Settings > Network Settings? Sometimes Bitmessage takes time to connect to the network. Please allow at least 30 minutes for it to connect before posting to the forum.<br />
<br />
If none of that works, [https://bitmessage.org/forum/index.php please visit the forum here.] <br />
<br />
===I have not received a reply from the Echo Server===<br />
*Your connection indicator should be yellow or green.<br />
*Make sure that your POW is complete and the message has been sent. You should see an acknowledgement under "Status" on the "Sent" tab. <br />
*On average it should take 8 minutes from the time you click the send button to the time you receive a response. <br />
*Be sure to allow extra time in the event that the server is under heavy traffic (Example: An article about Bitmessage was posted on a popular website).<br />
*You can always send a message to another echo server. Here are two echo addresses:<br />
** BM-orkCbppXWSqPpAxnz6jnfTZ2djb5pJKDb<br />
** BM-omXeTjutKWmYgQJjmoZjAG3u3NmaLEdZK<br />
<br />
If you still do not receive a response, [https://bitmessage.org/forum/index.php visit the forum] to see if there is a current technical issue or to submit a new request for assistance.<br />
<br />
===Other===<br />
Please [https://bitmessage.org/forum/index.php visit the forum] for all other issues.</div>Dokhttps://wiki.bitmessage.org/index.php?title=FAQ&diff=18804FAQ2013-05-15T17:06:56Z<p>Dok: /* I have not received a reply from the Echo Server */</p>
<hr />
<div>==Installation and configuration==<br />
===How do I install Bitmessage===<br />
A great write up for setting up and using Bitmessage on Windows can be found [http://cryptojunky.com/blog/2013/03/09/setting-up-and-using-bitmessage-an-encrypted-communications-platform-based-on-bitcoin/ Here.]<br />
<br />
Bitmessage should run on any OS though it is only lightly tested on OSX. The start-on-boot and minimize-to-tray features are only implemented for Windows thus far. Several examples of how to install Bitmessage on *nix and OSX platforms can be found [https://bitmessage.org/forum/index.php in the forums.]<br />
<br />
===How do I become a node to help the network===<br />
If your connection indicator is green then you are already accepting incoming connections and helping the Bitmessage network.<br />
<br />
If your connection indicator is yellow, check your firewall settings and port forwarding to make sure incoming connections are allowed to your machine on the correct port (Default TCP 8444).<br />
<br />
You can click on the indicator for more information about each color.<br />
<br />
===Why is my Connection Indicator Yellow===<br />
Bitmessage will work normally with a yellow indicator. If your indicator is yellow, you can have up to 8 connections and you are not acting as a relay node for the network. To make your indicator green and act as a relaying node for the Bitmessage network, please forward TCP port 8444 (default).<br />
<br />
===How do I setup Bitessage to work with Tor===<br />
<br />
'''Tor'''<br />
<br />
If you are using the Tor Browser Bundle skip to the next section. In order for Bitmessage to use Tor as a proxy follow these steps.<br />
*Navigate to Settings > Network Settings and select SOCKS5 from the Type: drop down under the Proxy server / Tor section.<br />
*Next to 'Server hostname:' enter 'localhost' and next to 'Port:' enter '9050'.<br />
*Select ok.<br />
*Restart Bitmessage.<br />
<br />
<br />
'''Tor Browser Bundle'''<br />
*Navigate to Settings > Network Settings and select SOCKS5 from the Type: drop down under the Proxy server / Tor section.<br />
*Next to 'Server hostname:' enter 'localhost' and next to 'Port:' enter '9150'.<br />
*Select ok.<br />
*Restart Bitmessage.<br />
<br />
==Usage==<br />
===How can I run Bitmessage in daemon mode===<br />
Refer to the [https://bitmessage.org/wiki/Daemon Daemon Mode Page Here.]<br />
<br />
===How many connections should I have===<br />
As long as you have at least one connection, you can communicate with the network. If your connection indicator is yellow, you can have a maximum of 8 connections.<br />
<br />
===Can I send a message to someone that is offline===<br />
Yes. However, if you go offline then they must come back online within 2 days of the message being sent. Nodes delete data, and do not accept data, older than 2 days. <br />
<br />
===How do I format my messages===<br />
Here is the list of supported HTML tags. [hhttps://qt-project.org/doc/qt-4.8/richtext-html-subset.html https://qt-project.org/doc/qt-4.8/richtext-html-subset.html]<br />
<br />
==How does Bitmessage work==<br />
'''Startup'''<br />
<br />
When you first start Bitmessage, your client connects itself to the network and starts downloading a list of known nodes. Each new node that you connect to shares its list of known nodes. In addition to the known nodes, you will also start receiving person-to-person messages, broadcasts, and public keys. If any of these messages are bound for you, they will be shown in your inbox. All of this data is exchanged between all of your connections to make sure that everyone has a copy. <br />
<br />
<br />
'''Sending a Message'''<br />
<br />
When you send a message, your client must first compute a Proof of Work (POW). This POW helps mitigate spam on the network. Nodes and other clients will not process your message if it does not show sufficient POW. After the POW is complete, your message is shared to all of your connections which in turn share it with all of their connections. <br />
<br />
===Where can I find more documentation about Bitmessage===<br />
* [https://bitmessage.org/bitmessage.pdf Overview White Paper (PDF)]<br />
* [https://bitmessage.org/wiki/Protocol_specification Protocol Specification]<br />
* [https://bitmessage.org/wiki/Proof_of_work Detail about the Proof of Work]<br />
<br />
==How does Bitmessage compare to other messaging methods==<br />
Here is a table comparing Bitmessage to other common messaging services.<br />
<br />
{| border="1" class="wikitable"<br />
|+ Comparison of Messaging Services<br />
! &nbsp;<br />
! Trustless<br />
! P2P<br />
! Open Source<br />
! Requires Proof of Work<br />
! Hide Sender?<br />
! Hide Receiver?<br />
! Mobile Version<br />
! Application or Web Based<br />
! Text Only Messages<br />
! Attachments<br />
! Acknowledge delivery<br />
|-<br />
! Bitmessage<br />
| Yes<br />
| Yes<br />
| [http://opensource.org/licenses/mit-license.php MIT]<br />
| Yes<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| No<br />
| Small only<br />
| Yes<br />
|-<br />
! Standard Email<br />
| <br />
| No<br />
| Depends<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| No<br />
| Yes<br />
| No<br />
|-<br />
! Email + GPG<br />
| Yes<br />
| No<br />
| Depends<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| Yes<br />
| No<br />
| No<br />
|-<br />
! [https://en.wikipedia.org/wiki/Off-the-Record_Messaging OTR]<br />
| Yes<br />
| No<br />
| GPL V2.1<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/TorChat TorChat]<br />
| Yes<br />
| Yes<br />
| GPL<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
! [http://www.skype.com/en/ Skype]<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| No<br />
| Yes<br />
| <br />
|-<br />
! [http://www.scayl.com/ Scayl]<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Alpha<br />
| Application<br />
| No<br />
| Very Large<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/I2P#E-mail I2P Bote]<br />
| Yes<br />
| Yes<br />
| GPL V3<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
! [https://crypto.cat/ CryptoCat]<br />
| No<br />
| No<br />
| GPL<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/Internet_Relay_Chat IRC]<br />
| <br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! SMS<br />
| <br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| No<br />
| Yes<br />
| No<br />
|-<br />
! [http://retroshare.sourceforge.net/ RetroShare]<br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/Freenet#Tools_and_applications Freenet + Frost]<br />
| Yes<br />
| Yes<br />
| GPL<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
! [https://mirror4.freenetproject.org/tools.html Freenet + FMS]<br />
| No<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://mirror4.freenetproject.org/tools.html Freenet + Freemail] 0.2<br />
| No<br />
| Yes<br />
| GPL<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Application<br />
| No<br />
| Yes <br />
| No<br />
|-<br />
! [https://wiki.freenetproject.org/FLIP Freenet + FLIP]<br />
| Yes<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| No<br />
| No<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|}<br />
<br />
<br />
==Troubleshooting==<br />
===My Connection Indicator is Red===<br />
Check your connection settings. Can you access the internet? Have you allowed Bitmessage through your firewall? Have you tried a different port number under Settings > Network Settings? Sometimes Bitmessage takes time to connect to the network. Please allow at least 30 minutes for it to connect before posting to the forum.<br />
<br />
If none of that works, [https://bitmessage.org/forum/index.php please visit the forum here.] <br />
<br />
===I have not received a reply from the Echo Server===<br />
*Your connection indicator should be yellow or green.<br />
*Make sure that your POW is complete and the message has been sent. You should see an acknowledgement under "Status" on the "Sent" tab. <br />
*On average it should take 8 minutes from the time you click the send button to the time you receive a response. <br />
*Be sure to allow extra time in the event that the server is under heavy traffic (Example: An article about Bitmessage was posted on a popular website).<br />
*You can always send a message to another echo server. Here are two echo addresses:<br />
** BM-orkCbppXWSqPpAxnz6jnfTZ2djb5pJKDb<br />
** BM-omXeTjutKWmYgQJjmoZjAG3u3NmaLEdZK<br />
<br />
If you still do not receive a response, [https://bitmessage.org/forum/index.php visit the forum] to see if there is a current technical issue or to submit a new request for assistance.<br />
<br />
===Other===<br />
Please [https://bitmessage.org/forum/index.php visit the forum] for all other issues.</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18799Feature request list2013-05-15T06:55:23Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
<strike>* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18798Feature request list2013-05-15T06:32:02Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* Show a percentage complete on "Doing work necessary to send the message" and maybe even display the time it took once finished.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
<strike>* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18797Feature request list2013-05-15T06:16:51Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
* View the PoW required for an address. UI warning when sending to an address that has a very high PoW setting.<br />
<br />
* UI setting to stop trying to send messages after X hours/days/months. <br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
* Ability to check the status of sent messages and being able to trash them.<br />
<br />
* Find the PoW requirement for an address (not local).<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
<strike>* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Compiling_instructions&diff=18782Compiling instructions2013-05-13T21:16:06Z<p>Dok: /* Ubuntu */ typo</p>
<hr />
<div>This page should help novice users run Bitmessage from the source code files.<br />
<br />
= Linux =<br />
== Ubuntu ==<br />
There's an unofficial Personal Package Archive for Pybitmessage which provides an easy way to get Pybitmessage. To install it, open a [https://help.ubuntu.com/community/UsingTheTerminal#Starting_a_Terminal Terminal] (press Ctrl+Alt+T) and enter the following:<br />
sudo add-apt-repository -y ppa:fuzzgun/pybitmessage && sudo apt-get update<br />
sudo apt-get install pybitmessage<br />
<br />
== From source ==<br />
<small>''Note for Fedora users: Fedora does not currently compile EC into OpenSSL and thus will not work. A workaround is needed to either recompile OpenSSL, or locate/install a OpenSSL package that supports EC extensions.''</small><br />
<br />
<small>''Note for Debian Wheezy (6.0) users: Debian Wheezy does not offer packages (like Python, OpenSSL) in versions that are needed for Bitmessage. You can still try to [https://github.com/Bitmessage/PyBitmessage/issues/47#issuecomment-17774377 work around these problems].''</small><br />
<br />
; Install dependencies:<br />
: APT-based distributions (Debian, Ubuntu): <code>sudo apt-get install python openssl git python-qt4</code><br />
: RPM-based distributions (Red Hat, Fedora): <code>sudo yum install python openssl git</code><br />
<br />
; Download and run Bitmessage:<br />
git clone <nowiki>https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage</nowiki><br />
python $HOME/PyBitmessage/src/bitmessagemain.py<br />
<br />
<small>Optionally create a startup script that runs '''python PyBitmessage/src/bitmessagemain.py'''</small><br />
<br />
= Windows =<br />
# Download and install the latest revision of Python 2.7 (currently Python 2.7.3 from [http://www.python.org/download/releases/2.7.3/ here]). The ''Windows x86 MSI Installer'' is the right choice for most people. (64-bit users may want the 64-bit version).<br />
# Test that it installed:<br />
## Open a command prompt by going to Start > Run. Type 'cmd' then press enter.<br />
## type 'python'. If python is installed, you should see the python version and the prompt: '>>>'<br />
## If you see a message such as: "'Python is not recognized as an internal or external command..." then you must add the python path to your path environmental variable:<br />
### Find the location where Python was installed (in particular, the location where python.exe exists). It might simply be in c:\Python2.7 <br />
### Follow [http://www.computerhope.com/issues/ch000549.htm these directions] to add the Python path to your path variable.<br />
### Close the command prompt window and reopen it. <br />
### Try running 'python' again.<br />
##Press Ctrl-Z to exit Python.<br />
# Bitmessage has two dependencies. The first is PyQt. Download and install PyQt from [http://www.riverbankcomputing.com/software/pyqt/download here]. You will want the Binary Package since it is already compiled for you. Be sure to select the version for Python 2.7. It is labeled as Py2.7. <br />
# The second dependency is OpenSSL which you can download from [http://slproweb.com/products/Win32OpenSSL.html here]. There you will also notice the link to download the Visual C++ 2008 program in case you also find that you need that as well. (The OpenSSL installer will complain if you need to install the Visual C++ Redistributable.)<br />
# Download the source code for PyBitmessage from GitHub. If it is in a zip file, you will need to extract it. There should be a few files and a few folders where one of the folders is 'src'. <br />
# To run Bitmessage, navigate into the 'src' folder and then double click on the bitmessagemain.py file, or in a command prompt, change directories to the 'src' directory which holds bitmessagemain.py and type 'python bitmessagemain.py'. <br />
<br />
== If you change user interface files ==<br />
You can use Qt's Designer application to modify the user interface. After you do this, you will need to 'compile' .ui files into .py files. <br />
# In a command prompt, change directories to the directory of your .ui file.<br />
# Run 'pyuic4 example.ui > example.py' If you get a message similar to 'pyuic4 is not recognized as an internal or external command' then you must add the PyQt directory to your system's path variable. This directory should hold pyuic4.bat. It might be in C:\Python27\Lib\site-packages\PyQt4. Remember to close the command window and reopen it after you change your path variable.<br />
<br />
If you add icons to bitmessage_icons.qrc, then you must run this command:<br />
pyrcc4 bitmessage_icons.qrc -o bitmessage_icons_rc.py<br />
<br />
== Optional: Compile into a stand-alone EXE ==<br />
# Download [http://www.pyinstaller.org/ PyInstaller].<br />
# Copy all of the source code files from the 'src' directory to the PyInstaller directory (which contains pyinstaller.py). <br />
# Run 'pyinstaller.py --onefile --noconsole --icon="images\can-icon.ico" bitmessagemain.py'<br />
This won't include the OpenSSL DLL file in the EXE; if you send it to someone who doesn't have OpenSSL installed, it will not run. To include the DLL file in the EXE, you must follow these steps:<br />
# After following the steps above, you will see that pyinstaller created a folder called bitmessagemain. In that folder is a file: bitmessagemain.spec. Open it with a text editor.<br />
# Below the line "a.datas," add this line: <code>a.binaries + [('libeay32.dll', 'c:\\windows\\system32\\libeay32.dll', 'BINARY')],</code><br />
# Save and close<br />
# Run this command: pyinstaller.py bitmessagemain/bitmessagemain.spec</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18754Feature request list2013-05-08T19:37:34Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
* 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.<br />
** 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.<br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
<strike>* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18750Feature request list2013-05-08T04:26:43Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
* Change labels on identities (also fixes the problem of not being able to assign an label to deterministic addresses via the API)<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
<strike>* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18744Feature request list2013-05-06T15:45:19Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy) <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
==Network==<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)<br />
<br />
==Accepted Requests (Implemented in version 0.3.0 and before)==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
<strike>* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18729Feature request list2013-05-03T21:51:02Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
<strike>* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy)<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary. <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
** 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? <br />
<br />
==Network==<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18728Feature request list2013-05-03T21:43:20Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
<strike>* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy)<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary. <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> I would rather not add another button; please clear them manually for now.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
** 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.<br />
<br />
==Network==<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** That sounds good to me. Can is also be a DNS entry instead of just an IP for adding a node?<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address. ATHEROS EDIT: What is the use case for this one?<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities.<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* <strike>Headless operation.</strike>[[Daemon|Done]]<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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.<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18714Feature request list2013-05-02T23:23:44Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
<strike>* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy)<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary. <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> Please clear them manually for now.<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
==Network==<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** I suppose that would work. I would think that the average user would be more likely to specify their own node than ignore the default known nodes. Ignoring default known nodes would be used in a LAN setup or someone not wanting to connect to the defaults for security reasons. However, since you have to run bitmessage to generate the keys file that has to be modified, changing this value should delete the knownnodes file. Otherwise a LAN setup would still have outside addresses that it would connect to for no reason. Can there be a check box next to the as-yet-to-be-added UI ip entry field? along with a "forget all known nodes" button? The checkbox could simply flip the value in keys.dat.<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities. <br />
<br />
<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Headless operation.<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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. <br />
<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18702Feature request list2013-05-02T06:36:07Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
<strike>* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy)<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary. <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> Please clear them manually for now.<br />
<br />
* Allow Bitmessage to work with computers sleep mode. (<strike>What?</strike> Currently bitmessage does not work after the computer resumes from sleep.)<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
==Network==<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* Ability to add a node to 'defaultKnownNodes' via IPv4, IPv6, or DNS (easy)<br />
<br />
* 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)<br />
** 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?<br />
** I suppose that would work. I would think that the average user would be more likely to specify their own node than ignore the default known nodes. Ignoring default known nodes would be used in a LAN setup or someone not wanting to connect to the defaults for security reasons. However, since you have to run bitmessage to generate the keys file that has to be modified, changing this value should delete the knownnodes file. Otherwise a LAN setup would still have outside addresses that it would connect to for no reason. Can there be a check box next to the as-yet-to-be-added UI ip entry field? along with a "forget all known nodes" button? The checkbox could simply flip the value in keys.dat.<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities. <br />
<br />
<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Headless operation.<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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. <br />
<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)</div>Dokhttps://wiki.bitmessage.org/index.php?title=FAQ&diff=18701FAQ2013-05-01T20:19:04Z<p>Dok: </p>
<hr />
<div>==Installation and configuration==<br />
===How do I install Bitmessage===<br />
A great write up for setting up and using Bitmessage on Windows can be found [http://cryptojunky.com/blog/2013/03/09/setting-up-and-using-bitmessage-an-encrypted-communications-platform-based-on-bitcoin/ Here.]<br />
<br />
Bitmessage should run on any OS though it is only lightly tested on OSX. The start-on-boot and minimize-to-tray features are only implemented for Windows thus far. Several examples of how to install Bitmessage on *nix and OSX platforms can be found [https://bitmessage.org/forum/index.php in the forums.]<br />
<br />
===How do I become a node to help the network===<br />
If your connection indicator is green then you are already accepting incoming connections and helping the Bitmessage network.<br />
<br />
If your connection indicator is yellow, check your firewall settings and port forwarding to make sure incoming connections are allowed to your machine on the correct port (Default TCP 8444).<br />
<br />
You can click on the indicator for more information about each color.<br />
<br />
===Why is my Connection Indicator Yellow===<br />
Bitmessage will work normally with a yellow indicator. If your indicator is yellow, you can have up to 8 connections and you are not acting as a relay node for the network. To make your indicator green and act as a relaying node for the Bitmessage network, please forward TCP port 8444 (default).<br />
<br />
===How do I setup Bitessage to work with Tor===<br />
<br />
'''Tor'''<br />
<br />
If you are using the Tor Browser Bundle skip to the next section. In order for Bitmessage to use Tor as a proxy follow these steps.<br />
*Navigate to Settings > Network Settings and select SOCKS5 from the Type: drop down under the Proxy server / Tor section.<br />
*Next to 'Server hostname:' enter 'localhost' and next to 'Port:' enter '9050'.<br />
*Select ok.<br />
*Restart Bitmessage.<br />
<br />
<br />
'''Tor Browser Bundle'''<br />
*Navigate to Settings > Network Settings and select SOCKS5 from the Type: drop down under the Proxy server / Tor section.<br />
*Next to 'Server hostname:' enter 'localhost' and next to 'Port:' enter '9150'.<br />
*Select ok.<br />
*Restart Bitmessage.<br />
<br />
==Usage==<br />
===How can I run Bitmessage in daemon mode===<br />
Refer to the [https://bitmessage.org/wiki/Daemon Daemon Mode Page Here.]<br />
<br />
===How many connections should I have===<br />
As long as you have at least one connection, you can communicate with the network. If your connection indicator is yellow, you can have a maximum of 8 connections.<br />
<br />
===Can I send a message to someone that is offline===<br />
Yes. However, if you go offline then they must come back online within 2 days of the message being sent. Nodes delete data, and do not accept data, older than 2 days. <br />
<br />
===How do I format my messages===<br />
Here is the list of supported HTML tags. [hhttps://qt-project.org/doc/qt-4.8/richtext-html-subset.html https://qt-project.org/doc/qt-4.8/richtext-html-subset.html]<br />
<br />
==How does Bitmessage work==<br />
'''Startup'''<br />
<br />
When you first start Bitmessage, your client connects itself to the network and starts downloading a list of known nodes. Each new node that you connect to shares its list of known nodes. In addition to the known nodes, you will also start receiving person-to-person messages, broadcasts, and public keys. If any of these messages are bound for you, they will be shown in your inbox. All of this data is exchanged between all of your connections to make sure that everyone has a copy. <br />
<br />
<br />
'''Sending a Message'''<br />
<br />
When you send a message, your client must first compute a Proof of Work (POW). This POW helps mitigate spam on the network. Nodes and other clients will not process your message if it does not show sufficient POW. After the POW is complete, your message is shared to all of your connections which in turn share it with all of their connections. <br />
<br />
===Where can I find more documentation about Bitmessage===<br />
* [https://bitmessage.org/bitmessage.pdf Overview White Paper (PDF)]<br />
* [https://bitmessage.org/wiki/Protocol_specification Protocol Specification]<br />
* [https://bitmessage.org/wiki/Proof_of_work Detail about the Proof of Work]<br />
<br />
==How does Bitmessage compare to other messaging methods==<br />
Here is a table comparing Bitmessage to other common messaging services.<br />
<br />
{| border="1" class="wikitable"<br />
|+ Comparison of Messaging Services<br />
! &nbsp;<br />
! Trustless<br />
! P2P<br />
! Open Source<br />
! Requires Proof of Work<br />
! Hide Sender?<br />
! Hide Receiver?<br />
! Mobile Version<br />
! Application or Web Based<br />
! Text Only Messages<br />
! Attachments<br />
! Acknowledge delivery<br />
|-<br />
! Bitmessage<br />
| Yes<br />
| Yes<br />
| [http://opensource.org/licenses/mit-license.php MIT]<br />
| Yes<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| No<br />
| Small only<br />
| Yes<br />
|-<br />
! Standard Email<br />
| <br />
| No<br />
| Depends<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| No<br />
| Yes<br />
| No<br />
|-<br />
! Email + GPG<br />
| Yes<br />
| No<br />
| Depends<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| Yes<br />
| No<br />
| No<br />
|-<br />
! [https://en.wikipedia.org/wiki/Off-the-Record_Messaging OTR]<br />
| Yes<br />
| No<br />
| GPL V2.1<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/TorChat TorChat]<br />
| Yes<br />
| Yes<br />
| GPL<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
! [http://www.skype.com/en/ Skype]<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| No<br />
| Yes<br />
| <br />
|-<br />
! [http://www.scayl.com/ Scayl]<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Alpha<br />
| Application<br />
| No<br />
| Very Large<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/I2P#E-mail I2P Bote]<br />
| Yes<br />
| Yes<br />
| GPL V3<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
! [https://crypto.cat/ CryptoCat]<br />
| No<br />
| No<br />
| GPL<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/Internet_Relay_Chat IRC]<br />
| <br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! SMS<br />
| <br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| No<br />
| Yes<br />
| No<br />
|-<br />
! [http://retroshare.sourceforge.net/ RetroShare]<br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/Freenet#Tools_and_applications Freenet + Frost]<br />
| Yes<br />
| Yes<br />
| GPL<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
! [https://mirror4.freenetproject.org/tools.html Freenet + FMS]<br />
| No<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://mirror4.freenetproject.org/tools.html Freenet + Freemail] 0.2<br />
| No<br />
| Yes<br />
| GPL<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Application<br />
| No<br />
| Yes <br />
| No<br />
|-<br />
! [https://wiki.freenetproject.org/FLIP Freenet + FLIP]<br />
| Yes<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| No<br />
| No<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|}<br />
<br />
<br />
==Troubleshooting==<br />
===My Connection Indicator is Red===<br />
Check your connection settings. Can you access the internet? Have you allowed Bitmessage through your firewall? Have you tried a different port number under Settings > Network Settings? Sometimes Bitmessage takes time to connect to the network. Please allow at least 30 minutes for it to connect before posting to the forum.<br />
<br />
If none of that works, [https://bitmessage.org/forum/index.php please visit the forum here.] <br />
<br />
===I have not received a reply from the Echo Server===<br />
*Your connection indicator should be yellow or green.<br />
*Make sure that your POW is complete and the message has been sent. You should see an acknowledgement under "Status" on the "Sent" tab. <br />
*On average it should take 8 minutes from the time you click the send button to the time you receive a response. Be sure to allow extra time in the event that the server is under heavy traffic.<br />
*You can always send a message to another echo server. Here are two additional echo addresses:<br />
** BM-orkCbppXWSqPpAxnz6jnfTZ2djb5pJKDb<br />
** BM-omXeTjutKWmYgQJjmoZjAG3u3NmaLEdZK<br />
<br />
If you still do not receive a response, [https://bitmessage.org/forum/index.php visit the forum] to see if there is a current technical issue or to submit a new request for assistance.<br />
<br />
===Other===<br />
Please [https://bitmessage.org/forum/index.php visit the forum] for all other issues.</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18697Feature request list2013-05-01T18:36:04Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
<strike>* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) </strike> Done<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy)<br />
<br />
* <strike>Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)</strike> Done. After trashing a message, restart Bitmessage ''immediately''. There currently still is no notification that restarting Bitmessage is necessary. <br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* <strike>A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]</strike> Broadcasts are now encrypted so this won't work.<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* 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.<br />
<br />
* <strike>Cancel sending a new message (clear all of the fields)</strike> Please clear them manually for now.<br />
<br />
* Allow Bitmessage to work with computers sleep mode. (<strike>What?</strike> Currently bitmessage does not work after the computer resumes from sleep.)<br />
<br />
* <strike>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')</strike><br />
** Because there are no servers, we can't tell when a message was sent with any certainty- the sender of a message can lie.<br />
** 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?).<br />
==Network==<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* Ability to add a node to 'defaultKnownNodes' (easy)<br />
<br />
* 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)<br />
** 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?<br />
** I suppose that would work. I would think that the average user would be more likely to specify their own node than ignore the default known nodes. Ignoring default known nodes would be used in a LAN setup or someone not wanting to connect to the defaults for security reasons. However, since you have to run bitmessage to generate the keys file that has to be modified, changing this value should delete the knownnodes file. Otherwise a LAN setup would still have outside addresses that it would connect to for no reason. Can there be a check box next to the as-yet-to-be-added UI ip entry field? along with a "forget all known nodes" button? The checkbox could simply flip the value in keys.dat.<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* <strike>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.</strike> Done<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities. <br />
<br />
<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Headless operation.<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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. <br />
<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18673Feature request list2013-04-25T15:44:12Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) (--Isn't this done in 0.2.8?)<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy)<br />
<br />
* Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)<br />
** ATHEROS EDIT: Adding a check that runs every time a POW iteration is done would slow it down. How about if you trash a message and then restart Bitmessage? I'll make the necessary changes so that it doesn't restart the POW for trashed messages.<br />
** Works for me, as long as a notification is displayed notifying the user that they need to restart the client<br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* Network info in the status bar. Current upload/download speeds as well as total uploaded/downloaded since startup.<br />
<br />
* Cancel sending a new message (clear all of the fields)<br />
<br />
* Allow bitmessage to work with computers sleep mode.<br />
<br />
* 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')<br />
<br />
<br />
==Network==<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* Ability to add a node to 'defaultKnownNodes' (easy)<br />
<br />
* 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)<br />
** 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?<br />
** I suppose that would work. I would think that the average user would be more likely to specify their own node than ignore the default known nodes. Ignoring default known nodes would be used in a LAN setup or someone not wanting to connect to the defaults for security reasons. However, since you have to run bitmessage to generate the keys file that has to be modified, changing this value should delete the knownnodes file. Otherwise a LAN setup would still have outside addresses that it would connect to for no reason. Can there be a check box next to the as-yet-to-be-added UI ip entry field? along with a "forget all known nodes" button? The checkbox could simply flip the value in keys.dat.<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* 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.<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities. <br />
<br />
<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Headless operation.<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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. <br />
<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18672Feature request list2013-04-25T15:19:06Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) (--Isn't this done in 0.2.8?)<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy)<br />
<br />
* Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)<br />
** ATHEROS EDIT: Adding a check that runs every time a POW iteration is done would slow it down. How about if you trash a message and then restart Bitmessage? I'll make the necessary changes so that it doesn't restart the POW for trashed messages.<br />
** Works for me, as long as a notification is displayed notifying the user that they need to restart the client<br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* Network info in the status bar. Current upload/download speeds as well as total uploaded/downloaded since startup.<br />
<br />
* Cancel sending a new message (clear all of the fields)<br />
<br />
* Allow bitmessage to work with computers sleep mode.<br />
<br />
<br />
==Network==<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* Ability to add a node to 'defaultKnownNodes' (easy)<br />
<br />
* 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)<br />
** 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?<br />
** I suppose that would work. I would think that the average user would be more likely to specify their own node than ignore the default known nodes. Ignoring default known nodes would be used in a LAN setup or someone not wanting to connect to the defaults for security reasons. However, since you have to run bitmessage to generate the keys file that has to be modified, changing this value should delete the knownnodes file. Otherwise a LAN setup would still have outside addresses that it would connect to for no reason. Can there be a check box next to the as-yet-to-be-added UI ip entry field? along with a "forget all known nodes" button? The checkbox could simply flip the value in keys.dat.<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* 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.<br />
<br />
* Use UPnP to open incoming ports on gateway router.<br />
<br />
==API==<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities. <br />
<br />
<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Headless operation.<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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. <br />
<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18625Feature request list2013-04-17T21:21:51Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) (--Isn't this done in 0.2.8?)<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy)<br />
<br />
* Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)<br />
** ATHEROS EDIT: Adding a check that runs every time a POW iteration is done would slow it down. How about if you trash a message and then restart Bitmessage? I'll make the necessary changes so that it doesn't restart the POW for trashed messages.<br />
** Works for me, as long as a notification is displayed notifying the user that they need to restart the client<br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* Network info in the status bar. Current upload/download speeds as well as total uploaded/downloaded since startup.<br />
<br />
* Cancel sending a new message (clear all of the fields)<br />
<br />
<br />
==Network==<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* Ability to add a node to 'defaultKnownNodes' (easy)<br />
<br />
* 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)<br />
** 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?<br />
** I suppose that would work. I would think that the average user would be more likely to specify their own node than ignore the default known nodes. Ignoring default known nodes would be used in a LAN setup or someone not wanting to connect to the defaults for security reasons. However, since you have to run bitmessage to generate the keys file that has to be modified, changing this value should delete the knownnodes file. Otherwise a LAN setup would still have outside addresses that it would connect to for no reason. Can there be a check box next to the as-yet-to-be-added UI ip entry field? along with a "forget all known nodes" button? The checkbox could simply flip the value in keys.dat.<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* 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.<br />
<br />
==API==<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities. <br />
<br />
<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Headless operation.<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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. <br />
<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18617Feature request list2013-04-15T15:13:45Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) (--Isn't this done in 0.2.8?)<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy)<br />
<br />
* Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)<br />
** ATHEROS EDIT: Adding a check that runs every time a POW iteration is done would slow it down. How about if you trash a message and then restart Bitmessage? I'll make the necessary changes so that it doesn't restart the POW for trashed messages.<br />
** Works for me, as long as a notification is displayed notifying the user that they need to restart the client<br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* Network info in the status bar. Current upload/download speeds as well as total uploaded/downloaded since startup.<br />
<br />
* Cancel sending a new message (clear all of the fields)<br />
<br />
<br />
==Network==<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* Ability to add a node to 'defaultKnownNodes' (easy)<br />
<br />
* 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)<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
* 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.<br />
<br />
<br />
==API==<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities. <br />
<br />
<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Headless operation.<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
* 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. <br />
<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18612Feature request list2013-04-14T05:52:30Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) (--Isn't this done in 0.2.8?)<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy)<br />
<br />
* Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)<br />
** ATHEROS EDIT: Adding a check that runs every time a POW iteration is done would slow it down. How about if you trash a message and then restart Bitmessage? I'll make the necessary changes so that it doesn't restart the POW for trashed messages.<br />
** Works for me, as long as a notification is displayed notifying the user that they need to restart the client<br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* Network info in the status bar. Current upload/download speeds as well as total uploaded/downloaded since startup.<br />
<br />
* Cancel sending a new message (clear all of the fields)<br />
<br />
<br />
==Network==<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* Ability to add a node to 'defaultKnownNodes' (easy)<br />
<br />
* 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)<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
<br />
==API==<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities. <br />
<br />
<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Headless operation.<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the download area. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)</div>Dokhttps://wiki.bitmessage.org/index.php?title=Feature_request_list&diff=18611Feature request list2013-04-14T05:48:42Z<p>Dok: </p>
<hr />
<div>==GUI/User Interaction==<br />
* <strike>Show addresses without the hyphen (easy, under discussion)</strike> abandoned<br />
<br />
* <strike>Accept addresses without the hyphen (easy)</strike> Done, accepts address without "BM-"<br />
<br />
* On Address book tab, add right-click option to add person to subscription list (easy)<br />
<br />
* Sounds (<strike>easy.</strike> This is turning out to be more difficult; there doesn't seem to be a simple cross-platform method of playing sounds)<br />
<br />
* <strike>Ability to trash sent messages(easy)</strike> Done<br />
<br />
* <strike>Clear the 'Send' tab after sending message or when acknowledgement received. (easy) </strike> Done<br />
<br />
* <strike>Trim input when adding an subscription or address book address (very easy)</strike> Done<br />
<br />
* Clicking the Windows notification balloon (New Message) will bring the Bitmessage window to focus. (----)<br />
<br />
* <strike>Do not open new messages automatically, and indicate if a message has been read. (----)</strike> Done<br />
<br />
* <strike> 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). (----) </strike> Basically done- see above.<br />
<br />
* <strike>Ability to select multiple recipients on the Address Book tab before clicking "Send message to this address"</strike> Done<br />
<br />
* User can adjust font and font size for easy reading.<br />
<br />
* A search feature for the inbox and sent items <br />
<br />
* <strike>Ability to create subfolders and move inbox items into them. Also a rules dialog for automatically classifying new mail into subfolders.</strike> 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.<br />
<br />
* Don't remove focus from current message when a new message arrives and denote unread messages (should be relatively easy, will require database changes) (--Isn't this done in 0.2.8?)<br />
<br />
* <strike>Allow a label to be set when creating addresses. A number is appended when creating multiple addresses (easy) </strike> You can already do this.<br />
<br />
* <strike>Ability to disable and re-enable a subscription address. (easy)</strike> Done<br />
<br />
* Ability to delete addresses from "Your Identities" (Keeping the current enable/disable options). (easy)<br />
<br />
* Cancel messages in the sent folder before they are sent. (Sending them to trash does not work.)<br />
** ATHEROS EDIT: Adding a check that runs every time a POW iteration is done would slow it down. How about if you trash a message and then restart Bitmessage? I'll make the necessary changes so that it doesn't restart the POW for trashed messages.<br />
** Works for me, as long as a notification is displayed notifying the user that they need to restart the client<br />
<br />
* GUI interface for adding attachments to outgoing message and opening incoming attachments.<br />
<br />
* 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?)<br />
<br />
* <strike>Built in text editor to send rich text natively.</strike> 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.<br />
<br />
* A tab for browsing the broadcast streams. [https://bitmessage.org/forum/index.php/topic,1560.0.html working example shown here]<br />
<br />
* Ability to star or otherwise highlight a message (to find easier later). Open to other methods of accomplishing this.<br />
<br />
* Network info in the status bar. Current upload/download speeds as well as total uploaded/downloaded since startup.<br />
<br />
* Cancel sending a new message (clear all of the fields)<br />
<br />
<br />
==Network==<br />
<br />
* <strike>Add support for SOCKS5 proxies (difficult)</strike> Done<br />
<br />
* Ability to add a node to 'defaultKnownNodes' (easy)<br />
<br />
* 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)<br />
<br />
* Allow LAN operation (or option to allow LAN operation (disabling non-private WAN ip ranges?)). <br />
** ATHEROS EDIT: How about being able to add an IP in the user interface? <br />
** 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).<br />
<br />
<br />
==API==<br />
* <strike>RPC API (difficult)</strike> Done<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1448.msg1677.html#msg1677 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)<br />
<br />
* Refresh GUI inbox (for example after deleting messages)<br />
<br />
* Retrieve the private key for an address<br />
<br />
* Add/Remove and Retrieve addresses from address book. <br />
<br />
* Add/Remove addresses to/from Blacklist/Whitelist.<br />
<br />
* Add/Remove address to/from Subscriptions<br />
<br />
* <strike>Add</strike>/Remove address to/from identities. <br />
<br />
<br />
<br />
==Backend==<br />
<br />
* 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.<br />
<br />
* <strike>Portable mode (easy)</strike> Done<br />
<br />
* <strike>Pseudo-mailing list mode for individual addresses (easy) https://github.com/Bitmessage/PyBitmessage/issues/51 </strike> Done <br />
<br />
* Offline mode (easy)<br />
<br />
* Option to export keys.dat and messages.dat files to an encrypted backup (medium, possibly difficult)<br />
<br />
* Separate messages.dat file into message.dat and addressbook.dat (easy. I might not do this.)<br />
<br />
* Headless operation.<br />
<br />
* Multi Threading up to the number of cores installed when creating addresses or sending Messages (Medium)<br />
<br />
* [https://bitmessage.org/forum/index.php/topic,1555.0.html Better logging] (medium)<br />
<br />
<br />
==Wiki/Forum==<br />
<br />
* Add MD5 checksum to the wiki Main Page. (easy)<br />
<br />
* Add GnuPG sig file to download area. (easy)</div>Dokhttps://wiki.bitmessage.org/index.php?title=FAQ&diff=18608FAQ2013-04-14T05:03:11Z<p>Dok: </p>
<hr />
<div>==Installation and configuration==<br />
===How do I install Bitmessage?===<br />
A great write up for setting up and using Bitmessage on Windows can be found [http://cryptojunky.com/blog/2013/03/09/setting-up-and-using-bitmessage-an-encrypted-communications-platform-based-on-bitcoin/ Here.]<br />
<br />
Bitmessage should run on any OS though it is only lightly tested on OSX. The start-on-boot and minimize-to-tray features are only implemented for Windows thus far. Several examples of how to install Bitmessage on *nix and OSX platforms can be found [https://bitmessage.org/forum/index.php in the forums.]<br />
<br />
===How do I become a node to help the network?===<br />
If your connection indicator is green then you are already accepting incoming connections and helping the Bitmessage network.<br />
<br />
If your connection indicator is yellow, check your firewall settings and port forwarding to make sure incoming connections are allowed to your machine on the correct port (Default TCP 8444).<br />
<br />
You can click on the indicator for more information about each color.<br />
<br />
===Why is my Connection Indicator Yellow?===<br />
Bitmessage will work normally with a yellow indicator. If your indicator is yellow, you can have up to 8 connections and you are not acting as a relay node for the network. To make your indicator green and act as a relaying node for the Bitmessage network, please forward TCP port 8444 (default).<br />
<br />
===How do I setup Bitessage to work with Tor?===<br />
<br />
'''Tor'''<br />
<br />
If you are using the Tor Browser Bundle skip to the next section. In order for Bitmessage to use Tor as a proxy follow these steps.<br />
*Navigate to Settings > Network Settings and select SOCKS5 from the Type: drop down under the Proxy server / Tor section.<br />
*Next to 'Server hostname:' enter 'localhost' and next to 'Port:' enter '9050'.<br />
*Select ok.<br />
*Restart Bitmessage.<br />
<br />
<br />
'''Tor Browser Bundle'''<br />
*Navigate to Settings > Network Settings and select SOCKS5 from the Type: drop down under the Proxy server / Tor section.<br />
*Next to 'Server hostname:' enter 'localhost' and next to 'Port:' enter '9150'.<br />
*Select ok.<br />
*Restart Bitmessage.<br />
<br />
==Usage==<br />
===How many connections should I have?===<br />
As long as you have at least one connection, you can communicate with the network. If your connection indicator is yellow, you can have a maximum of 8 connections.<br />
<br />
===Can I send a message to someone that is offline?===<br />
Yes. However, if you go offline then they must come back online within 2 days of the message being sent. Nodes delete data, and do not accept data, older than 2 days. <br />
<br />
===How do I format my messages?===<br />
Here is the list of supported HTML tags. [hhttps://qt-project.org/doc/qt-4.8/richtext-html-subset.html https://qt-project.org/doc/qt-4.8/richtext-html-subset.html]<br />
<br />
==How does Bitmessage work?==<br />
'''Startup'''<br />
<br />
When you first start Bitmessage, your client connects itself to the network and starts downloading a list of known nodes. Each new node that you connect to shares its list of known nodes. In addition to the known nodes, you will also start receiving person-to-person messages, broadcasts, and public keys. If any of these messages are bound for you, they will be shown in your inbox. All of this data is exchanged between all of your connections to make sure that everyone has a copy. <br />
<br />
<br />
'''Sending a Message'''<br />
<br />
When you send a message, your client must first compute a Proof of Work (POW). This POW helps mitigate spam on the network. Nodes and other clients will not process your message if it does not show sufficient POW. After the POW is complete, your message is shared to all of your connections which in turn share it with all of their connections. <br />
<br />
===Where can I find more documentation about Bitmessage?===<br />
* [https://bitmessage.org/bitmessage.pdf Overview White Paper (PDF)]<br />
* [https://bitmessage.org/wiki/Protocol_specification Protocol Specification]<br />
* [https://bitmessage.org/wiki/Proof_of_work Detail about the Proof of Work]<br />
<br />
==How does Bitmessage compare to other messaging methods?==<br />
Here is a table comparing Bitmessage to other common messaging services.<br />
<br />
{| border="1" class="wikitable"<br />
|+ Comparison of Messaging Services<br />
! &nbsp;<br />
! Trustless<br />
! P2P<br />
! Open Source<br />
! Requires Proof of Work<br />
! Hide Sender?<br />
! Hide Receiver?<br />
! Mobile Version<br />
! Application or Web Based<br />
! Text Only Messages<br />
! Attachments<br />
! Acknowledge delivery<br />
|-<br />
! Bitmessage<br />
| Yes<br />
| Yes<br />
| [http://opensource.org/licenses/mit-license.php MIT]<br />
| Yes<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| No<br />
| Small only<br />
| Yes<br />
|-<br />
! Standard Email<br />
| <br />
| No<br />
| Depends<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| No<br />
| Yes<br />
| No<br />
|-<br />
! Email + GPG<br />
| Yes<br />
| No<br />
| Depends<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| Yes<br />
| No<br />
| No<br />
|-<br />
! [https://en.wikipedia.org/wiki/Off-the-Record_Messaging OTR]<br />
| Yes<br />
| No<br />
| GPL V2.1<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/TorChat TorChat]<br />
| Yes<br />
| Yes<br />
| GPL<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
! [http://www.skype.com/en/ Skype]<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| No<br />
| Yes<br />
| <br />
|-<br />
! [http://www.scayl.com/ Scayl]<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Alpha<br />
| Application<br />
| No<br />
| Very Large<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/I2P#E-mail I2P Bote]<br />
| Yes<br />
| Yes<br />
| GPL V3<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
! [https://crypto.cat/ CryptoCat]<br />
| No<br />
| No<br />
| GPL<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/Internet_Relay_Chat IRC]<br />
| <br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Both<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! SMS<br />
| <br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
| Application<br />
| No<br />
| Yes<br />
| No<br />
|-<br />
! [http://retroshare.sourceforge.net/ RetroShare]<br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
|-<br />
! [https://en.wikipedia.org/wiki/Freenet#Tools_and_applications Freenet + Frost]<br />
| Yes<br />
| Yes<br />
| GPL<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
! [https://mirror4.freenetproject.org/tools.html Freenet + FMS]<br />
| No<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| Yes<br />
| No<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|-<br />
! [https://mirror4.freenetproject.org/tools.html Freenet + Freemail] 0.2<br />
| No<br />
| Yes<br />
| GPL<br />
| No<br />
| No<br />
| No<br />
| No<br />
| Application<br />
| No<br />
| Yes <br />
| No<br />
|-<br />
! [https://wiki.freenetproject.org/FLIP Freenet + FLIP]<br />
| Yes<br />
| Yes<br />
| <br />
| No<br />
| No<br />
| No<br />
| No<br />
| Application<br />
| Yes<br />
| No<br />
| <br />
|}<br />
<br />
<br />
==Troubleshooting==<br />
===My Connection Indicator is Red===<br />
Check your connection settings. Can you access the internet? Have you allowed Bitmessage through your firewall? Have you tried a different port number under Settings > Network Settings? Sometimes Bitmessage takes time to connect to the network. Please allow at least 30 minutes for it to connect before posting to the forum.<br />
<br />
If none of that works, [https://bitmessage.org/forum/index.php please visit the forum here.] <br />
<br />
===I have not received a reply from the Echo Server===<br />
*Your connection indicator should be yellow or green.<br />
*Make sure that your POW is complete and the message has been sent. You should see an acknowledgement under "Status" on the "Sent" tab. <br />
*On average it should take 8 minutes from the time you click the send button to the time you receive a response. Be sure to allow extra time in the event that the server is under heavy traffic.<br />
*You can always send a message to another echo server. Here are two additional echo addresses:<br />
** BM-orkCbppXWSqPpAxnz6jnfTZ2djb5pJKDb<br />
** BM-omXeTjutKWmYgQJjmoZjAG3u3NmaLEdZK<br />
<br />
If you still do not receive a response, [https://bitmessage.org/forum/index.php visit the forum] to see if there is a current technical issue or to submit a new request for assistance.<br />
<br />
===Other===<br />
Please [https://bitmessage.org/forum/index.php visit the forum] for all other issues.</div>Dok