GitHub repository: Bitmessage/PyBitmessage

Issues:
issue_2164: state: open
title: Appimage release 
body: Please add appimage file to release
   https://appimage.bitmessage.org/releases/20230116/
 
   And information that if it doesn't work, installing fuse will probably solve the problem. 
user: nuke3
issue_2158: state: open
title: Newbie on Linux(Ubuntu) with AppImage
body: Hi !
I am using latest Appimage (which is from January) on Ubuntu 22.04 (tried to build myself but failed - missing deps). So I can run it from AppImage, but I can't get it to green. So I use port 8144 (which I configured on router to passthrough to my Ip address) and I have Socks 5 configured on localhost: 9150). 
All my other software (like qbttorrent) manages to negotiate with my Router with UpNp, but not Bit meesage, which is why I added static route to my router. 
I ahve tor browser running at same time, with hope that this will work... 

I am not sure if the problem is with my app image or with my network configuration... 

I am total newbie with Tor and PyBitMessage, so I might be doing some very basic mistake... Any pointers to right direction, would be very welcome.
user: andyrozman
issue_2150: state: open
title: Refactor sqlthread
body: ## Repository contributions to the PyBitmessage project

### Code

- Try to refer to github issue tracker or other permanent sources of discussion about the issue.
- It is clear from the diff *what* you have done, it may be less clear *why* you have done it so explain why this change is necessary rather than what it does.

### Documentation

Use `tox -e py27-doc` to build a local copy of the documentation.

### Tests

- If there has been a change to the code, there's a good possibility there should be a corresponding change to the tests
- To run tests locally use `tox` or `./run-tests-in-docker.sh`

## Translations

- For helping with translations, please use [Transifex](https://www.transifex.com/bitmessage-project/pybitmessage/).
- There is no need to submit pull requests for translations.
- For translating technical terms it is recommended to consult the [Microsoft Language Portal](https://www.microsoft.com/Language/en-US/Default.aspx).

### Gitiquette

- Make the pull request against the ["v0.6" branch](https://github.com/Bitmessage/PyBitmessage/tree/v0.6)
- PGP-sign the commits included in the pull request
- Use references to tickets, e.g. `addresses #123` or `fixes #234` in your commit messages
- Try to use a good editor that removes trailing whitespace, highlights potential python issues and uses unix line endings
- If for some reason you don't want to use github, you can submit the patch using Bitmessage to the "bitmessage" chan, or to one of the developers.


user: shportix
issue_2146: state: open
title: Update mistune requirement from <=0.8.4 to <2.0.6
body: Updates the requirements on [mistune](https://github.com/lepture/mistune) to permit the latest version.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/lepture/mistune/releases">mistune's releases</a>.</em></p>
<blockquote>
<h2>Version 2.0.5</h2>
<p>Improve on parsing list. Make it possible to customize list regex. ref <a href="https://github-redirect.dependabot.com/lepture/mistune/issues/331">lepture/mistune#331</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/lepture/mistune/commit/cb580e89e67ef9b4827daf43afd2058bdf5e58d2"><code>cb580e8</code></a> Version bump 2.0.5</li>
<li><a href="https://github.com/lepture/mistune/commit/2c55e9c40a61aaee8a2212ea6ecd4a87493cf739"><code>2c55e9c</code></a> ignore invalid python versions</li>
<li><a href="https://github.com/lepture/mistune/commit/71c97743488c9988c8bb8abab3a97a5947c13746"><code>71c9774</code></a> Fix list parser for customized list grammar.</li>
<li><a href="https://github.com/lepture/mistune/commit/1264a1c954396fa31304bfac39588381f015a5d8"><code>1264a1c</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/lepture/mistune/issues/316">#316</a> from jieter/patch-1</li>
<li><a href="https://github.com/lepture/mistune/commit/77e928e83d0f7b5bf31cf4a0a9deec67d2503449"><code>77e928e</code></a> Use absolute import in Spoiler example, add markdown syntax</li>
<li><a href="https://github.com/lepture/mistune/commit/13b84cb911b825e3f3842987f838971213e71763"><code>13b84cb</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/lepture/mistune/issues/313">#313</a> from timgates42/bugfix_typo_parameter</li>
<li><a href="https://github.com/lepture/mistune/commit/88c54da5013441d48fc1f079091d8f7f4b54f06a"><code>88c54da</code></a> docs: fix simple typo, paramter -&gt; parameter</li>
<li><a href="https://github.com/lepture/mistune/commit/b92a5febd4da3d7097a3d2b8d7cac6f5d57ea20c"><code>b92a5fe</code></a> Version bump 2.0.4</li>
<li><a href="https://github.com/lepture/mistune/commit/98a1c0afc51d4be719cb17401a35e62f46206915"><code>98a1c0a</code></a> Fix url plugin render, <a href="https://github-redirect.dependabot.com/lepture/mistune/issues/308">#308</a></li>
<li><a href="https://github.com/lepture/mistune/commit/979d6d3bfc7d6159f38deb8e751611e4205033f6"><code>979d6d3</code></a> Fix * parsing, <a href="https://github-redirect.dependabot.com/lepture/mistune/issues/312">#312</a></li>
<li>Additional commits viewable in <a href="https://github.com/lepture/mistune/compare/v0.1.0...v2.0.5">compare view</a></li>
</ul>
</details>
<br />


Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)


</details>
user: dependabot[bot]
labels: dependencies: Pull requests that update a dependency file
issue_2143: state: open
title: Change copyright year to 2023
body: Change copyright year to 2023
user: sandakersmann
issue_2142: state: open
title: Add transifexrc file
body: Add transifexrc file for transifex translation
user: osamacis
issue_2139: state: open
title: *
body: *
user: ghost
issue_2136: state: open
title: Add localization for UI
body: Add localization for UI
user: osamacis
issue_2106: state: open
title: Refactoring SWAP64 in bitmsghash.cl
body: Refactoring SWAP64 in bitmsghash.cl
user: teruteru128
issue_2104: state: open
title: Add label argument to createChan API endpoint
body: jsonrpclib throws errors sometimes due to the auto-generated labels that are based on the passphrases I set. Example:

```(-32603, '<class 'api.APIError'>:API Error 0021: Unexpected API Failure - bad interpolation variable reference '%(793569%(4"]'')```

This "%(793569%(4"]" is a substring of my label that's based on the passphrase and the error prevents any data from being received.

Because the passphrases I use are generated in a specific way, I can't just exclude certain character combinations as possibilities. Therefore, I propose adding the ability to set the label at the time of the chan creation, which will allow me to set the label to something different/safer than the passphrase.
user: 813492291816
issue_2087: state: open
title: Bump kivymd from 1.0.2 to 1.1.1
body: Bumps [kivymd](https://github.com/kivymd/KivyMD) from 1.0.2 to 1.1.1.
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/kivymd/KivyMD/commit/fd5f598b91fef230c8b5a0a3e59e4115d9a40540"><code>fd5f598</code></a> KivyMD 1.1.1</li>
<li><a href="https://github.com/kivymd/KivyMD/commit/ae3fee12f57797d3fe571b3baf64e2bb92e688d5"><code>ae3fee1</code></a> KivyMD 1.2.0.dev0</li>
<li><a href="https://github.com/kivymd/KivyMD/commit/539acaa7bc43f76e1ca606d11627d714265215fc"><code>539acaa</code></a> KivyMD 1.1.0</li>
<li><a href="https://github.com/kivymd/KivyMD/commit/f49f29b6eed21bb3dc67736fe34d162b8092fc1b"><code>f49f29b</code></a> Edit doc string</li>
<li><a href="https://github.com/kivymd/KivyMD/commit/a1b8d7b9fe40c55f56220a2305a1e7b6a07c1a33"><code>a1b8d7b</code></a> Edit doc string</li>
<li><a href="https://github.com/kivymd/KivyMD/commit/69d2c4dbb72d4ac648509532d1507cb6fa05a416"><code>69d2c4d</code></a> Edit doc string</li>
<li><a href="https://github.com/kivymd/KivyMD/commit/8a015cec30dfcfb7f4b5c3ea6571f9c1f2945039"><code>8a015ce</code></a> Edit doc string</li>
<li><a href="https://github.com/kivymd/KivyMD/commit/2134f3a92a72a751a6b47136a1f371467b09da6b"><code>2134f3a</code></a> Edit doc string</li>
<li><a href="https://github.com/kivymd/KivyMD/commit/635bd7a2ca5f99d43b3026bc2064a5bc04d22460"><code>635bd7a</code></a> Edit doc string</li>
<li><a href="https://github.com/kivymd/KivyMD/commit/ac33f3c2e46db66d9e4aca74862ed95ed26de2d7"><code>ac33f3c</code></a> Edit doc string</li>
<li>Additional commits viewable in <a href="https://github.com/kivymd/KivyMD/compare/1.0.2...1.1.1">compare view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=kivymd&package-manager=pip&previous-version=1.0.2&new-version=1.1.1)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)


</details>
user: dependabot[bot]
labels: dependencies: Pull requests that update a dependency file
issue_2086: state: open
title: Arch Linux is missing a maintainer
body: Because of #1712 I am disowning the pybitmessage-git package on the AUR. I'm happy to maintain the package again when python3 is supported.
user: dmp1ce
issue_2077: state: open
title: update spec file with requirements param
user: surbhicis
issue_2075: state: open
title: Update docutils requirement from <=0.17.1 to <0.20.0
body: Updates the requirements on [docutils](https://docutils.sourceforge.io/) to permit the latest version.


Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)


</details>
user: dependabot[bot]
labels: dependencies: Pull requests that update a dependency file
issue_2040: state: open
title: Pyelliptic is deprecated
body: File `highlevelcrypto.py` uses the `pyelliptic` pip library, but this one is deprecated since 2017. I suppose that this one needs to be replaced with an up to date crypto library like [Pyca/cryptography](https://github.com/pyca/cryptography).
user: Jeroenvb3
issue_1999: state: open
title: Refactor sqlthread and add create test cases
user: shekhar-cis
issue_1991: state: open
title: Bitmesage Plus enhanced security
body: Bitmessage Plus is a paper designed to enhance security of Bitmessage. Think you might like this and if practical implement it

https://ieeexplore.ieee.org/document/9343829
user: PowerPress
issue_1984: state: open
title: APPImage doesn't connect anymore 
body: Hi,
Since a 2 weeks or so my APPImage (0.6.3.2) doesn't connect to TOR anymore.
I haven't changed anything in the settings.
Is there any issue on the side of BitMessage or a new version I should download?
Thanks for your support.
user: Cottonwoodhill
issue_1946: state: open
title: No chance to run on -> macOS Monterey
body: I tried to get PyBitmessage run for hours now with all instruction infos but there is no way.

I tried brew and macports and both end in the same result.

I tested python, python2 and python3, all without succes. Also all kind of libcrypto versions end in the same result.

The client that is precompiled stucks and thats the reason i tried to run it myself.

Any idea how I can solve that?

```
% python src/bitmessagemain.py 
WARNING: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python is loading libcrypto in an unsafe way
zsh: abort      python src/bitmessagemain.py
```

```
python2.7 src/bitmessagemain.py
WARNING: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python is loading libcrypto in an unsafe way
zsh: abort      python2.7 src/bitmessagemain.py
```

```
python3 src/bitmessagemain.py
  File "/Users/christiangrieger/Github/PyBitmessage/src/bitmessagemain.py", line 404
    print 'Usage: ' + sys.argv[0] + ' [OPTIONS]'
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print('Usage: ' + sys.argv[0] + ' [OPTIONS]')?
```
user: ChristianGrieger
issue_1938: state: open
title: `dontconnect` UI test
body: `dontconnect` option is handled differently when using a UI, therefore the core tests don't pick up this code path. Once we have UI tests, we need to add a separate UI test for `dontconnect`
user: PeterSurda
issue_1923: state: open
title: Outdated installment instructions
body: The installment/compiling instruction for Ubuntu 20+ are an absolute mess, nothing works as described and you have to figure out a lot of things yourself. Would appreciate better instructions/documentation 

Especially an update to python 3+ is more than overdue...
user: ghost
issue_1902: state: open
title: mac OS build using darling
body: [Darling](https://www.darlinghq.org) is an implementation of macOS system interfaces on linux, similarly like [wine](https://www.winehq.org) is an implementation of Windows system on linux. Based on my research there is a good chance building macOS binaries of PyBitmessage using Darling will work, i.e. produce binaries that will work on macOS. The environment appears to be compatible with macOS 10.15 Catalina, and xcode command line tools 12.4. Unfortunately there is some work left on python2 and Qt4 compatibility which prevents the build from progressing, so I got stuck. I made a fork of qt4 and python2 casks so we can make patched versions until a python3 / Qt5 port is working.

Once a build procedure is available, it can be plugged into the existing build system by running on a ubuntu VM. I don't think it will work in docker as it needs a special kernel module, which isn't very stable, running it in a VM is the official recommended process of the darling project.

A lack of mac OS binary is preventing a new release, so it would be nice if this was solved.
user: PeterSurda
labels: build: Related to building or build system
issue_1896: state: open
title: PEP8 violations in the recently merged code
body: Hi!

It seems nobody cares about PEP8 and formatting anymore. The recently merged code is formatted like shit, as well as the commit messages, which are still meaningless ):

Two years ago I added [the comment](https://github.com/Bitmessage/PyBitmessage/commit/69a7dc594aa8d080deb1f7d13107002638d6714c#diff-fa602a8a75dc9dcc92261bac5f533c2a85e34fcceaff63b3a3a81d9acde2fc52R4) in `setup.cfg` about max-line-length and it's still there. Your check `buildbot/PyBitmessage-pylint` is also still failing.
user: g1itch
labels: formatting: Code or UI text formatting
issue_1892: state: open
title: Dockerfile arm architecture
body: The `buildscripts/docker/Dockerfile.bionic` doesn't work on arm architecture (Apple M1, Raspberry Pi, ...).
user: PeterSurda
labels: build: Related to building or build system
issue_1889: state: open
title: sendBroadcast ackdata inconsistent
body: Sometimes API tests for `sendBroadcast` fail, and it looks like the `ackdata` that is returned by `helper_sent.insert` is inconsistent with the `ackdata` which is returned when reading the corresponding database column afterwards.
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_1885: state: open
title: Build docs using python3
body: Hi!

After reading the RTFD build logs for the [rebased doc branch](https://github.com/g1itch/PyBitmessage/tree/doc) I decided to update the documentation build procedure to python3. Now at least it [succeeds](https://pybitmessage-test.readthedocs.io/en/doc-python3/).
user: g1itch
issue_1883: state: open
title: Added mock code
body: Added mock code for class_objectProcessor, class_singleWorker, inventory, connectionpool & stats
user: kdcis
issue_1880: state: open
title: Update installation documentation for setuptools
body: `bitmessagemain.py` can't be executed directly anymore due to removing of relative imports (well technically it can but you still need to build the modules first). Installation documentation needs to be updated to reflect that you have to use setuptools.
user: PeterSurda
issue_1878: state: open
title: Mock classes/threads for backend
body: Create the following mock threads that can be used for UI tests

- [ ] worker (pretend to do PoW and mark message as sent after a while, or pretend the key doesn't exist)
- [ ] Object Processor (pretend objects are arriving from network and insert records into `inbox` or `pubkey` tables)
- [ ] Network thread (just return fake connections, bandwidth)

These will then be used for tests so that we have a more lightweight UI testing capability (Qt, kivy, ...)
Make them compatible with Python 2 and Python 3
user: PeterSurda
issue_1877: state: open
title: Will there ever be some stable tag released?
body: Dear all,
I wanted to ask if there will be some newer release - tag with a stable code base?
Last tag is back from 2018 and there is no clear release procedure that potential users could follow.

If you consider some branch / tag stable and secure enough, can you mention it in a readme or via tags/releases?

Thank you for your work. Have a nice day,
Peter
user: viralpoetry
issue_1857: state: open
title: Tests for namecoin
body: Namecoin connectivity has no tests.
user: PeterSurda
issue_1841: state: open
title: Moving away from the global context
body: Hello!

Your comment in #1839 triggered a huge reflection in my brain regarding the architecture of threads in the main package. I suddenly realized that they have the same birth injury as a `bitmessageqt` app: global context. I started a branch [incapsulation](https://github.com/g1itch/PyBitmessage/tree/incapsulation) where I'm going to address the issue in the `singeWorker` as an example. You cannot just take the current code and write a test case which start the `singeWorker` thread isolated from the rest ones, because it uses SQL, Inventory, queues and the shared objects...

In this ticket I'm going to describe the solutions I already found and formulated as they arrive, so we could continue the discussion, started in #1828.

The points so far:

- if the thread has it's own queue, where it takes commands, [init it with the queue](https://github.com/g1itch/PyBitmessage/commit/0978d7789d386c17f167ed9fa8f67342240c3341#diff-733625a72542a829f0ec5bd93fded7b7451f5c7f1f9a59997bf4d18ec4471a10R51)
- the same is applicable to other objects such as Inventory, BMConfigParser, etc.
- worker has nothing to do with `invQueue`, Inventory [can feed it itself](https://github.com/g1itch/PyBitmessage/commit/0978d7789d386c17f167ed9fa8f67342240c3341#diff-6cf2ada67d0ea7cbf66242ffe357fda3064d3312dad11718809bf7f5fa7eb07bR47)
- I'm prematurely introducing a new entity, `MsgBox`, the base class for Inbox, Outbox, etc. The worker needs it's method ~ `get_by_status()` for the queries like [this](https://github.com/Bitmessage/PyBitmessage/blob/v0.6/src/class_singleWorker.py#L725). The implementation is not have to be tied to the `SQLThread`.
- once all the objects passed directly to their consumers, **get rid of the Singleton anti-pattern**.

The minor issues can be addressed there:

- use something like `getattr(self, 'handle_{}'.format(command))` instead of the [if: else: ladder](https://github.com/Bitmessage/PyBitmessage/blob/v0.6/src/class_singleWorker.py#L149)
- try handle the exceptions where they were rised, reducing the duplicates
- move all assembly code into the `protocol` or it's imported submodule (e.g. fe691a5) and cover by tests

the latter will help removing all the pylint comments. You will also see why I hate those tiny formatting changes: I see most of those blocks removed or moved into another modules (e.g. cf8c3ac) but writing code takes time ):
user: g1itch
labels: enhancement: New feature
developers: The issue is relevant mainly for developers rather than users
issue_1834: state: open
title: Strange log messages started to appear with recent code changes
body: Hello!

With recent code I see this log message when opening any 'inbox' folder in the `bitmessageqt` app

```
2021-08-27 15:49:00,688 - WARNING - Section or Option did not found: No section: 'BM-2cXrFSw75fT5FP7qWbM86jpMTSGFBD7uLU'
2021-08-27 15:49:00,691 - WARNING - sendBroadcast didn't work
```
user: g1itch
labels: bug: Something isn't working as it's supposed to
issue_1796: state: open
title: Refactor using of crypto functions
body: In this branch I'm gonna cover by tests all the crypto functions used in code and do a refactoring. Basic points:

 * only `highlevelcrypto` should import from `pyelliptic`
 * `highlevelcrypto` should not depend on the app state e.g. module `state` or `BMConfigparser()` instance (the same will be done for `protocol` in #1788)
 * `highlevelcrypto` should include hashes - double sha512, ripemd160
 * finally I'm gonna detach `pyelliptic` into the separate repo to show a possible way of addressing #886
user: g1itch
issue_1794: state: open
title: Refactor sqlthread
body: Refactor sqlthread  and add test cases for setting versions and SQL internal function called create_function

user: cis-muzahid
issue_1773: state: open
title: Code quality
body: A couple of code quality fixes.
user: PeterSurda
labels: developers: The issue is relevant mainly for developers rather than users
issue_1768: state: open
title: Added flatpak build manifests with split dependencies
body: - Added Flatpak build manifests under ```packages/flatpak/``` directory

- Added Flatpak build instructions under ```docs/``` directory
user: kdcis
issue_1763: state: open
title: Current PyBitmessage establishes more outbound connections than set by 'maxoutboundconnections'
body: Hello!

Lately I constantly see 10 outbound connections on the "Network Status" tab of my PyBitmessage while 'maxoutboundconnections' is set to default 8. I added additional check to `TestCore.test_bootstrap()` and reproduced the issue in https://travis-ci.org/github/g1itch/PyBitmessage/builds/772095631.
user: g1itch
labels: bug: Something isn't working as it's supposed to
issue_1743: state: open
title: added kivy app code and telenium test cases
body: 1)Added kivy app code of python3 version.
2)Added python3_requirement.txt withj all kivy amd kivymd latest version.
3)Added main_test module for running telenium test cases
4)Added telenium test cases(Graphical test cases) for kivy desktop app
user: navjotcis
issue_1741: state: open
title: Addressbook ordering erratic
body: I received a report that the addressbook ordering doesn't seem to follow usable rules, the person complaining doesn't like it. It looks like it's addresses first, then subscriptions, and spaces and digits are screwed up. There perhaps should be a way to choose the sorting order.
user: PeterSurda
issue_1738: state: open
title: Screenshots in bitmessageqt tests
body: Hello!

This may address a part of #1711: not video but a working method to take screenshots. I also added `xvfbwrapper` into tests requirements for Linux and returned platform independent form `python src/bitmessagemain.py -t` to run core tests.
user: g1itch
issue_1722: state: open
title: update license copyright year to 2021
body: minor change to reflect the current year at LICENSE.md

user: kaue
issue_1720: state: open
title: make opencl interruptible
body: don't think it works now. Also write a test for it once implemented.
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_1715: state: open
title: create separate method for each currentVersion of class_sqlThread module
body: I have created a separate method for each version of the class_sqlThread module
and also added a decorator for removing repeated code.
user: navjotcis
issue_1712: state: open
title: python 3 port plan
body: Using the principles of continuous delivery, port to python 3 should progress as following:

- the first PR will add allow travis to run python3 while successfully doing nothing. The `pybitmessage` binary will check if it's running python 3 and if yes, exit with return code 0. Unit tests will be decorated to skip all tests when using python 3. This should allow travis to succeed in python 3. Not sure what to do if requirements.txt diverge between python 2 and python 3.
- gradually tests will be updated to allow running in python 3
- maybe new tests will be written to cater for areas that currently don't have tests to facilitate gradual porting
- once everything is working correctly in python 3, as well as binary builds for the main platforms, python 2 support will be dropped
user: PeterSurda
labels: developers: The issue is relevant mainly for developers rather than users
build: Related to building or build system
issue_1711: state: open
title: Visual tests
body: The GUI tests can be extended with something like https://github.com/cgoldberg/xvfbwrapper to produce a video. This can the be made available by buildbot for watching.
user: PeterSurda
issue_1710: state: open
title: SQL unit tests
body: - there should be a mechanism to do unit test for SQL calls outside of the core tests. Maybe have a setup method that spawns a sql thread
- the migrations between the versions need to have their own unit test, maybe these steps should be split into separate functions
- there should be some sample SQL dumps that are loaded before tests
user: PeterSurda
issue_1706: state: open
title: mac OS jpeg decoder missing
body: For some reason the official build can't decode jpeg. This is not a new problem, people reported it several times in the past. It predates the buildbot builds. I tried to manually install libjpeg before buildng qt and pyqt, but pyqt doesn't seem to build at the moment so I'm not sure how to fix it.
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_1705: state: open
title: mac OS locale problems
body: When trying to open PyBitmessage preferences on Big Sur, the window doesn't appear and there is some exception about a locale. Reproducible with current buildbot build. Haven't tested on other versions of mac OS.
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_1700: state: open
title: Better way of filtering core tests
body: There should be a better way to run core tests (tests which require some of the threads to be running) than to put them into `src/tests/core.py`. Maybe a decorator?
user: PeterSurda
issue_1695: state: open
title: Onion bootstrap server is down: add (a) new onion bootstrap server(s)
body: According to @g1itch in [a comment on](https://github.com/Bitmessage/PyBitmessage/issues/1538#issuecomment-703701796) #1538, the sole onion bootstrap server is down.  This poses extra problems when 'onionservicesonly=true' (old style) or 'onlynet=onion' (new style, see #1694): either bootstrapping stalls or we must connect to a non-onion endpoint.

I see at least two options here:
1. Project maintainers run a suitable node and use that as the onion bootstrapping service.  That may actually be the case for `quzwelsuziwqgpt2.onion` and it is just not properly maintained; I don't know who is responsible for that node.
2. A snapshot is taken and periodically updated of all or some large proportion of onion nodes known to the developers.  This snapshot is used in `startBootstrappers()` in `src/network/connectionpool.py`.


I prefer the second option as it is much more robust and removes single points of failure/surveillance.  However, many of those onion nodes are ephemeral onion addresses and so will quickly be useless.  Additionally, some users who may not want the increased load that comes from being a bootstrap node will be included without giving consent.

I am of course open to other ideas, too.
user: sgj3
issue_1694: state: open
title: Closes #1538. Refactors 'onionservicesonly' to 'onlynet=onion', prevents bootstrapping from non-onion nodes when true, and prevents bootstrapping from any node but the trusted peer (when set)
body: This PR fixes #1538.  It:
- Gracefully changes the config option 'onionservicesonly=true' to 'onlynet=onion', upgrading old config directives upon GUI settings dialog "OK"
- When onion services only is requested, prevents bootstrapping from a non-onion node
- When a trusted peer is set, prevents bootstrapping from any other node 

This PR *does not* add any warning or error dialogs, which would be useful for a user unknowingly unable to bootstrap because they set 'onlynet=onion'.

(Please ignore #1693. I accidentally hit ENTER when typing the title, which GitHub oh-so-helpfully interpreted as a click on "Create pull request".)
user: sgj3
issue_1692: state: open
title: Status of this project? Linux Binarys? Debian build issues? Better documentation? Debian Repos's etc?
body: I am a tinkerer and found this app relatively interesting, and would like to try it out, but it doesnt seem to get much activity these days. I would like to know what the status of this app is, especially after @PeterSurda got his keys compromised. Here are a few questions that I have:
1) Is this still under any real active development and actually being worked on anymore?
2) Is PeterSurda still heading this project?
3) Is PeterSurda Okay? 
4) Why are there no binaries for linux/debian, and can we ever expect any?
5) Can we ever expect this app to be packaged into a repo?
6) Why is this so difficult to run on debian with requirements/dependancies being those of outdated software including python?
7) On a scale of 1-10, what would be the security rating of this app in terms of how refined and audited the code is? 
8) How close to production level is this app?
9) Why are the instructions for debian so difficult and convoluted, with many dependancies being unlisted, and requirements to run the app being unlisted?
10) Do you need any help with documentation for this app on debian? It needs it badly.

Thanks for the answers and help. I like trying out experimental software and getting it to work properly. Let me know if there is anything I can do to assist with this project.

Danran 
user: Danrancan
issue_1671: state: open
title: fixed the app closing issue on the press of quit button
body: Here when user try to quit the app then the app does not close it takes time longer than expected so I have fixed it for two cases
1) when the user open the app and closes it before the connection popup shows then the app does not close. It runs in a loop for n no. of times which takes sometimes 2-3 minutes or longer then it so I have added the condition with it for checking if the user presses quit then it will not go into the loop and close the app.
2) This case appears sometimes so here also app not close when the user tries to quit because there is condition pendingDownload() > 0 so app-only close when pendingDownload() returns 0 or less so the value of pendingDownload()  method is not fixed sometimes it gives a large no. which run in the loop N no. of times so also it does not close the app until loop executes N no. of times so I have also added the condition here when the user press the quit then it does not go into the loop and close the app.
user: navjotcis
issue_1650: state: open
title: fixed CQ for bitmessageqt.retranslateui module
body: flake8
pycodestyle
pylint
user: coolguy-cell
issue_1641: state: open
title: No calculation of intersecting streams is performed
body: The code doesn't compare streams I'm interested in with remote node's advertised streams. This will trigger bugs once streams are fully implemented.

There should be a new property in `TCPConnection` which will be an intersection of `self.streams` with `BMConnectionPool().streams`.
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_1631: state: open
title: Streams redesign
body: The current streams design, even though not fully implemented, has in my opinion a significant drawback: in order to benefit from scaling adjustments, users have to create new addresses and abandon new ones. This proposal changes how an address' position in the binary tree is determined. The current design assigns an extra variable to determine this, and the position is then fixed. Instead, I propose that the location be determined as a combination of a global variable recommended depth, and a path derived starting from the least significant bit of the address (or pubkey).

Since #1612 eliminates pubkey/getpubkey objects, the sender always knows the recipients' public key and can thus calculate the path. The recommended depth can be determined by a variety of methods, at the beginning it can be centralised with a publicly available process so that it can be audited. Nodes will then reject objects whose streams don't have at least the recommended depth.

The objects, and nodes will still contain streams as in the current protocol, so their design doesn't need to change. Perhaps the interpretation needs to be adjusted. E.g. for node, the stream will also mean the minimum depth they require and a calculation needs to be performed if the arriving object is "under" the specified stream. It should be possible to do this efficiently using bit-wise operations. Only addresses need to be changed not to contain streams. Since #1612 needs to change the address structure anyway, the two changes can be implemented together.

The main advantages are that it is possible to scale easier on the fly, and that the changes to current design are small. I think also implementing it is easier. While the signalling of depth has potential weaknesses, the legacy design isn't better: there also isn't an agreed upon method for signalling when people should start generating addresses in new streams.
user: PeterSurda
labels: enhancement: New feature
developers: The issue is relevant mainly for developers rather than users
protocol: Protocol change
issue_1627: state: open
title: Global difficulty adjustments
body: The whitepaper specifies:

> The difficulty of the proof-of-work should be proportional to the size of the message and should be set such that an average computer must expend an average of four minutes of work in order to send a typical message.

From this perspective, the current difficulty is too low. I propose:

- a mechanism for announcing a difficulty change
- a transparent process for determining global difficulty
- a deadline by which the process is put into the place
- further research into whether the requirements specified in the whitepaper make sense

It is difficult to create a decentralised mechanism for determining the difficulty. Instead I propose a centralised solution based on a transparent mechanism. There could be a new object signed by a central authority announcing the current difficulty.

The process can take external sources of average consumer CPU, e.g. [Steam Hardware and Software Survey](https://store.steampowered.com/hwsurvey/cpus/) or [UserBenchmark](https://cpu.userbenchmark.com/SpeedTest/793/IntelR-CoreTM-i5-3570-CPU---340GHz). At the moment the average CPU looks to be a quad core Ivy Bridge Intel CPU. This can be used as a base for the initial change.

Then there is a question about what size of message should be considered "average", what TTL, and if the 4 minutes should include an ACK.
user: PeterSurda
labels: protocol: Protocol change
issue_1626: state: open
title: Python 3 support / Python 2 EOL
body: It would be good to switch to Python 3 with Python 2 being end-of-lifed.
user: ghost
labels: developers: The issue is relevant mainly for developers rather than users
issue_1621: state: open
title: Wine build fixes and version changes
body: **IGNORE, THIS IS FOR TESTING BUILDBOT** 

- bump OpenSSL to 1.0.2u and remove the old one that is included in PyQt
- add msvcr120.dll (needed by the new OpenSSL)
- bump python to 2.7.18
- OpenSSL is now cross-compiled with mingw to avoid problems with MSVCR
- downgrade PyInstaller for 64bit (was causing problems)
- upgrade PyInstaller for 32bit
user: PeterSurda
issue_1616: state: open
title: Chat-like message types and interface
body: During development of the android interface I realised that a chat-like interface may be more user friendly than an email-like interface. I propose a protocol change for chat-like objects. They would use a new message type, and a bit in the pubkey bitfield would indicate whether the address should be used for chat message types instead of email-like message type.

The chat message type would contain a reference to previous objects (so that ordering can be done by the client), and could contain UTF-8 text, images or audio (maybe with separate message types for each, or all in one). Video wouldn't fit within maximum object size, so can probably be skipped. For audio, I tested the [Opus](https://en.wikipedia.org/wiki/Opus_(audio_format)) codec, which produces about 7kbit/s file at the minimum size and still is understandable. Opus codec is widely supported by open source implementation and a [python package](https://pypi.org/project/opuslib/).

For compatibility outside of kivy, the QT interface would contain another tab for a chat interface. The API would have to be updated too.

For storing, a new table is proposed.

I also propose to extend the messagetype class to allow not only encoding / decoding, but also saving/loading/searching/etc. For old message types it can be refactored later.

This proposal can be implemented independently of my recent proposal for getting rid of pubkey objects #1612 .
user: PeterSurda
labels: enhancement: New feature
developers: The issue is relevant mainly for developers rather than users
protocol: Protocol change
mobile: Frontend for mobile devices (kivy)
issue_1613: state: open
title: Fix the issues with non-ASCII characters in path on Windows
body: Hello!

This is the fix for the bug on Windows which was recently reported back in chan. When the `messages.dat` file path contains unicode characters the exception `sqlite3.OperationalError: unable to open database file` is raised and PyBitmessage stops loading.

I'm not sure about necessity of the change in `class_sqlThread` (`os.path.join()` instead of strings concatenation). The main problem is in encoding of the `state.appdata` string. I used the solution from https://stackoverflow.com/questions/35833037.

Related issues are: #165, #978
user: g1itch
labels: bug: Something isn't working as it's supposed to
issue_1612: state: open
title: Protocol upgrade for new features
body: **Rationale:**

The protocol needs to be upgraded to allow for things like forward secrecy and anonymity,, compressed pubkeys. Issues mentioning forward secrecy: #454, #833, #1015 forward anonymity #563.

Furthermore, the current use of pubkey/getpubkey objects has some drawbacks, as pointed out by @gmaxwell (see thread e.g. here: https://www.reddit.com/r/bitmessage/comments/g2u4a5/how_bitmessage_keeps_your_anonymity/fnr5zry/ ). He proposes including the public key inside the address.

Summary of pubkey/getpubkey mechanism drawbacks:

- using pubkey/getpubkey prevents (or at least make difficult and non-standard) a fully passive recipient
- the sender needs to wait until they receive a pubkey, which often causes confusion for senders unfamiliar with the inner workings of the bitmessage
- the sender may end up unnecessarily creating a getpubkey before synced. This wastes PoW
- upon creation of a new address, the creator needs to do PoW, which may be a waste and may expose the creator
- more resource usage is worse for mobile devices

Summary of advantages of pubkey/getpubkey mechanism:

- allows to change some metadata (behavior bitfield and difficulty) without changing address. However, reacting to changed pubkey metadata currently isn't implemented very well and at least would need some design work on fixing
- easier to publish prekeys (e.g. for PFS). However, this isn't implemented yet anyway
- address is shorter. With some optimisation, the new format for an identifier may be cut down to max. 39 bytes, while the old one is 26.
- allows to use a separate key for signing and encryption. However this probably isn't necessary

There are some other minor issues, e.g. there is currently no signalling of support of extended encoding in the protocol, the hashing algorithm used for ECDSA signatures (SHA1 vs SHA256). The behavior bitfield is in my opinion unnecessarily long (4 bytes).

**Proposal**

I think it makes sense to modify the protocol (new message and broadcast versions) to:
1. obsolete old standards, like SHA1, old encodings (i.e. _simple_ and _trivial_, I think _ignore_ encoding can be still kept optionally for future use in onion routing).
2. fix issues like compressed pubkeys (pyelliptic now supports them)
3. remove pubkey/getpubkey
4. allow for easy adding of new features (e.g. there can be a section reserved for PFS which can be ignored until PFS is actually implemented).

Pubkeys can still be added in the future, for example as a helper for PFS. A node could refresh pubkey objects if the collection of prekeys (if we're using something like X3DH) or other data that is used for deriving session keys expires or are used up. Without PFS they probably aren't necessary, and even with PFS, the mechanism could allow reuse of long term key for the initial contact only.

PFS will most likely be implemented later, as the exact method has to be chosen, and also a suitable library, as I'm not sure OpenSSL is sufficient for any existing PFS mechanism.

A more detailed specification will follow later. I'm collecting feedback now.
user: PeterSurda
labels: enhancement: New feature
developers: The issue is relevant mainly for developers rather than users
protocol: Protocol change
issue_1610: state: open
title: MacOS - System Integrity Protection: enabled
body: Hi,

if i clone from the default branch and use the installation instruction from your website, i get the following error after running bitmessagemain.py:

`System Integrity Protection: enabled`

I know what it is but i don't wanne disable it. Is there onother way?

Here are my System-Details:
`
Identifier:            Python
Version:               2.7.17 (2.7.17)
Code Type:             X86-64 (Native)
Parent Process:        bash [9758]
Responsible:           Terminal [9756]
OS Version:            Mac OS X 10.15.2 (19C57)
`

Thanks




user: marcel-braun
labels: build: Related to building or build system
issue_1607: state: open
title: Make this application available as flatpak package on FlatHub
body: Hi. It will be very useful for Linux users if you make this application available as a flatpak package on FlatHub. Doing so you will make this application available for almost all Linux distors & users in very convenient & secure way ...... Open source applications when added as flatpaks on FlatHub will be in deterministic (reproducible package) & automatically updated & works on almost all Linux distros ... Moreover, flatpak is easier than & more convenient & more secure than AppImage ...... 

Retroshare make itself available on flatpak, so why Bitmessage not? - see:
https://www.flathub.org/apps/details/cc.retroshare.retroshare-gui

Best. 
user: Nokia808
labels: enhancement: New feature
issue_1603: state: open
title: Graphical QT Testing
body: **Graphical Qt Testing**

Initial commit for the graphical Qt tests. 
Build an automated script for Qt Interface- 
-Generate address with a random label
-Generate addresses with passphrases
-Send a message and checks whether the message received or not
-Add the address in the subscription list
-Add the address in the blacklist and whitelist
-Tests for setting window.
-Tests for Inbox tab QTreeWidget PopMenu
 Work is in progress. Kindly give me some feedbacks 
user: lakshyacis
issue_1601: state: open
title: Any success in implementing PFS?
body: Has anyone had any success in implementing PFS in bitmessage? Or any idea when it will arrive? It would provide a massive security boost.
user: PowerPress
labels: enhancement: New feature
protocol: Protocol change
issue_1597: state: open
title: Bootstrap test inconsistent
body: The boostrap test (e.g. on travis) sometimes fails. It probably is due to a fault in the test, client connection handling (drop a connection before downloading all the data), server connection handling (they drop connection before sending addresses or flushing the stream) or some combination thereof.

It's not exclusively a problem of travis, I'm moving the tests to buildbot and the same happens there. If you retry the test enough it will eventually succeed.

I'll check if the bootstrap servers that I have access to have the latest code, if that doesn't fix it maybe someone can look at it in more detail.

- [x] fix #1598
- [x] check bootstrap servers up to date
- [ ] check if test is working correctly
- [ ] check if servers send addresses if full / duplicate IP
- [ ] check if servers close the connection after the stream is flushed
- [ ] check if client closes connection after all data is read
- [ ] if it's still broken, investigate what else it could be
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
developers: The issue is relevant mainly for developers rather than users
issue_1579: state: open
title: Isolate and optimize knownnodes processing
body: Hello!

I decided to further debug the duplicate hosts issue in the branch [knownnodes-debug](https://github.com/g1itch/PyBitmessage/tree/knownnodes-debug). And now I think that `knownnodes` need some more checks and optimizations.

Work in progress.
user: g1itch
issue_1575: state: open
title: addrthread unfinished
body: looks like I forgot to finish it, it doesn't send anything into the network. It needs to be investigated.
user: PeterSurda
issue_1570: state: open
title: outdated Fedora package hint
user: dimyme
issue_1569: state: open
title: uncrumple settings window
body: to full size right away with no need to manually enlarge it
900 wide, less than 1024x78
user: dimyme
issue_1560: state: open
title: suppress those "Do you really want do this?" confirmations
body:  those "Do you really want do this?" are justified to varying degrees, but they slow down the power–users. 

So why don't we set a global vari "YES_REALLY_YES" read from settings initially and AND it with the popup confirmation dialogs.

I consider it an "enhancement" to usability! Maybe I do a PR myself. It is well known that too many confirmations are a real PITA though newbies might need them.

After all, once one has a quick copy of the file messages.dat what could possibly go wrong that cannot be corrected? very little, if anything.
user: dimyme
labels: enhancement: New feature
issue_1555: state: open
title: clean out unused files
body: I'm under the impression that some essentially unused files still linger in the src tree. such as NewAddressWizard.py which is even still imported but never run.

That stuff should be moved into /dev/ maybe together with the ui files that cannot be compiled properly. It leads to confusion to have that dead weight under /src/

All such relicts should be mercylessly uprooted! lets make a spring cleaning!

**adresses.py**  is another such dinosaur 
user: dimyme
labels: developers: The issue is relevant mainly for developers rather than users
issue_1551: state: open
title: The simpliest way to implement messagesencrypted
body: Hello!

It seems the 'messagesencrypted' setting may be implemented via [sqlcipher](../../../sqlcipher/sqlcipher) using [pysqlcipher](https://pypi.org/project/pysqlcipher/).
user: g1itch
labels: enhancement: New feature
issue_1544: state: open
title: Enable seamless, if crude, file attachment capability
body: See PR #1540.
user: sgj3
issue_1538: state: open
title: Add onlynet=onion config option
body: Please add an onlynet=onion configuration option like in Bitcoin Core to exclusively allow connections to Bitmessage nodes behind a Tor Onion Service for enhanced privacy at the network layer.
user: gousasin
issue_1535: state: open
title: The PyQt4 module is not available
body: I installed PyQt with Homebrew but it didn't work. Message from terminal:
 - ERROR - The PyQt4 module is not available.
My system is macOS 10.14.6

user: alekseika7
labels: build: Related to building or build system
issue_1534: state: open
title: Move all SQL queries into single module
body: Hello!

I'm going to replace most of duplicated `helper_sql.sqlExecute()` with several functions having obvious names, keyword arguments and all necessary checks. This changeset contains the most frequent queries.
user: g1itch
issue_1508: state: open
title: Qt interface delete sent handling
body: If a message is in queued or doing PoW, it shouldn't be possible to delete it. It can create problems.

Alternatively, the singleWorker thread can check for the message still being in the "sent" folder during intermediary steps.
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
developers: The issue is relevant mainly for developers rather than users
issue_1486: state: open
title: Maybe use DoH?
body: Hello!

Maybe PyBitmessage can benefit from using [DoH](https://github.com/stamparm/python-doh)?
user: g1itch
labels: enhancement: New feature
issue_1482: state: open
title: Confirm PM senders
body: Similarly to how mobile chat programs work, there should be a way (maybe using the blacklist / whitelist, we could add greylist or something to the option) to confirm new contacts.

1. sender sends a message to a new recipient
2. new recipient sees the message, but he also has a popup for whether to allow or block the sender
3. after allowing, sender can be added to addressbook
4. after blocking, it could go to spam or something

The details can be changed later. It probably needs one backend implementation and multiple UI ones (API, QT, kivy, ...).
user: PeterSurda
labels: enhancement: New feature
mobile: Frontend for mobile devices (kivy)
issue_1477: state: open
title: Windows EXE triggering antivirus false positives
body: It seems to happen with the 32bit version only. You can verify it by uploading the binary to https://www.virustotal.com/. Tests I did a couple of years ago indicated that this may be triggered by the PyInstaller bootloader, which is use by some malware. Recompiling the bootloader seems to have fixed it but I haven't done recent tests, and the new cross-compiled binaries seem to trigger it again.

It only happens with very few of the AV engines. I had tried submitting false positive removal requests, but in particular the Chinese ones don't have a working method for that.
user: PeterSurda
labels: developers: The issue is relevant mainly for developers rather than users
issue_1476: state: open
title: Subscription / payment screen
body: There should be a payment wizard for the subscription / payment, shown when people click on "Subscription / payment" in the kivy UI. This is the first iteration so it may change in the future. On the low level blind signatures will be used (#1409)

1. information about what it is for, and a choice between 100 credits and 500 credits. Selecting one will bring you to second page
2. choice of a distributor (at the begining, Bitmessage GmbH)
3. choice of a payment method (at the beginning, we can have bitcoin testnet, litecoin and bitcoin cash main net).
4. payment-specific handling. For cryptocurrencies, there can be new extended encoding type(s) for order and payment request. An example of the workflow, see https://github.com/PeterSurda/bitmessage-email-gateway. For other payments, maybe a redirect to a website or something.
5. for handling blind signatures, use dummy functions
6. store received credits (certified signatures) in messages.dat, so there needs to be a new table

There should be a section in the keys.dat determining which payment methods and distributors are available. There should also be a separate bitmessage account hidden from the UI for handling payment communications.

There also needs to be a backend counterpart. I'm not sure yet whether this will be a separate project using an API, or a bitmessage module using extended encoding.

user: PeterSurda
labels: enhancement: New feature
mobile: Frontend for mobile devices (kivy)
issue_1465: state: open
title: Onion-specific proxy not working
body: Typos in the code, some places use `onionproxy` and others `onion_proxy`. It never worked.
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_1461: state: open
title: kivy - Dynamic Address Book 
body: In this issue, when a new address is added to the address book, the user is redirected to the address book, but the data was not updated on the address book listing screen. For this before we implemented a refresh button on the address book to update the data. 

However, now we are working on, redirecting user to address book screen with dynamic Address listing on saving a new address. 
user: cis-s
labels: bug: Something isn't working as it's supposed to
mobile: Frontend for mobile devices (kivy)
issue_1460: state: open
title: kivy - [Bug Fix(Design)] Sent Mail Screen
body: In this task, we are working on design fix of Sent mail screen, as per the dynamic data displayed. 

The issue is due to the inconsistent length of the data in different input fields, which leads to design related bug on the screen. We are working on this to fix the design and automatic adjustment as per the content of the input fields.  
user: cis-s
labels: mobile: Frontend for mobile devices (kivy)
issue_1459: state: open
title: kivy - Switch Account Functionality
body: In this task, we are providing functionality for user to manage their multiple account on the same devices. In this, user can switch their account and check / send emails of / from particular account. 

In this we are providing a interface for user to list all of their account, and choose particular account.
user: cis-s
labels: enhancement: New feature
mobile: Frontend for mobile devices (kivy)
issue_1458: state: open
title: kivy - Dynamic Data Listing (Send Email)
body: The title PyBit-App refers to the Android mobile application. 
In this task, we are working on displaying dynamic data listing on sent email functionality. 
Also, this feature will provide instant data update (real time) without reload on the same page.

user: cis-s
labels: enhancement: New feature
mobile: Frontend for mobile devices (kivy)
issue_1456: state: open
title: Perma messages
body: There should be an option to make a mesage permanent, the corresponding object would be automatically re-created with a new expiration and PoW after the old one expires. This is helpful in particular for chans, so that you can see the message no matter when you join.
user: PeterSurda
labels: enhancement: New feature
issue_1449: state: open
title: PyBitmessage doesn't distinguish broadcasts from normal messages
body: Hello!

If you subscribe to BM address which is a chan, you'll see all messages received from the chan:
![bm_subscribe_chan](https://user-images.githubusercontent.com/4012700/55011654-dc661880-4fee-11e9-99c9-651b0f1c1f9c.png)

This behaviour seems to be wrong: only broadcasts should be shown on "Subscriptions" tab.
user: g1itch
labels: bug: Something isn't working as it's supposed to
issue_1444: state: open
title: Revocation bitfield
body: If a BM address is used for long-term authentication, there is a need to revoke it in case it gets compromised. Obviously, it is easy to create a new one, but there also should be a way to indicate to the user that an old address shouldn't be used.

The easiest way, in my opinion, is to add a new bitfield to an address, say BITFIELD_REVOKED, which can be turned on but not off (there needs to be some additional protection in the code so that simply editing keys.dat won't turn it off). The UI would then signal to the sender that they shouldn'd use it.

- [ ] Bitfield deifnition and a coresponnding variable in keys.dat
- [ ] UI for turning it on with warning and confirmations
- [ ] UI for showing (on the owner side) that an address is revoked, similarly to how disabled addresses are grayed out
- [ ] after revoked,  a new pubkey object should be sent immediately, not only after the old one expires
- [ ] Protection against turning it off in BMConfigParser
- [ ] Protection against turning it off in some other way
- [ ] objectProcessor should handle the bitfield and flag entries in the addressbook (may require additional colums in addressbook table). It should also protect the flag/bitfield from being turned off after it is on
- [ ] messagelist should change background color for messages from revoeked addresses (maybe only after revocation date?)
- [ ] Send tab should complain or perhaps even grey out the send button if a revoked address is used
- [ ] Autoreply?
- [ ] some other things I'm missing?
user: PeterSurda
labels: enhancement: New feature
protocol: Protocol change
issue_1438: state: open
title: packagemonkey link broken on INSTALL instructions
body: The INSTALL.md has a packagemonkey link which is not working. Should be updated. I tried an online search but could not get it still:
https://duckduckgo.com/?q=packagemonkey&t=canonical&ia=web
user: chandreshp
issue_1435: state: open
title: Should licence headers be turned into docstrings or remain a comments?
body: Hello!

That's the question arisen by recent rebase I've done (7f96b36). Some modules taken from third party (like `namecoin` or `network.asyncore_pollchoose`) have the licence headers which were turned into docstrings by @coffeedogs. Though I've seen a python packages with similar formatting style (like `jsonrpclib`) I still don't understand the reason to have the licenses in documentation.

Let's clarify the bitmessage's style guide in this case.
user: g1itch
issue_1426: state: open
title: Proof of Storage/Space/Replication/Etc?
body: Has anyone investigated whether some type of proof of space would be suitable for bm? It should narrow the gap between phones and desktops/GPUs/FPGAs. There are lots of pdfs on eprint.iacr.org about this topic. Latest ones seem to deal with proofs of replicated storage but that wouldn't be required for bm.
user: iljah
labels: protocol: Protocol change
issue_1418: state: open
title: ValueError: API 'QDate' has already been set to version 1`
body: I constantly get the following error:

`Loading existing config files from /root/.config/PyBitmessage/
Using default logger configuration
2018-10-09 14:26:55,215 - ERROR - /root/.namecoin/namecoin.conf unreadable or missing, Namecoin support deactivated
2018-10-09 14:26:55,368 - CRITICAL - Unhandled exception
Traceback (most recent call last):
  File "bitmessagemain.py", line 434, in <module>
    main()
  File "bitmessagemain.py", line 431, in main
    mainprogram.start()
  File "bitmessagemain.py", line 333, in start
    bitmessageqt.run()
  File "/root/PROGRAMS/PyBitmessage-0.6.3.2/src/bitmessageqt/__init__.py", line 4403, in run
    myapp = MyForm()
  File "/root/PROGRAMS/PyBitmessage-0.6.3.2/src/bitmessageqt/__init__.py", line 579, in __init__
    self.ui.setupUi(self)
  File "/root/PROGRAMS/PyBitmessage-0.6.3.2/src/bitmessageqt/bitmessageui.py", line 559, in setupUi
    self.blackwhitelist = Blacklist()
  File "/root/PROGRAMS/PyBitmessage-0.6.3.2/src/bitmessageqt/blacklist.py", line 17, in __init__
    widgets.load('blacklist.ui', self)
  File "/root/PROGRAMS/PyBitmessage-0.6.3.2/src/bitmessageqt/widgets.py", line 13, in load
    uic.loadUi(resource_path(resFile), widget)
  File "/usr/lib/python2.7/dist-packages/PyQt4/uic/__init__.py", line 236, in loadUi
    return DynamicUILoader(package).loadUi(uifile, baseinstance, resource_suffix)
  File "/usr/lib/python2.7/dist-packages/PyQt4/uic/Loader/loader.py", line 50, in __init__
    UIParser.__init__(self, QtCore, QtGui, LoaderCreatorPolicy(package))
  File "/usr/lib/python2.7/dist-packages/PyQt4/uic/uiparser.py", line 183, in __init__
    self.factory = QObjectCreator(creatorPolicy)
  File "/usr/lib/python2.7/dist-packages/PyQt4/uic/objcreator.py", line 94, in __init__
    modinfo = plugin_locals["moduleInformation"]()
  File "<string>", line 52, in moduleInformation
  File "/usr/lib/python2.7/dist-packages/qgis/__init__.py", line 26, in <module>
    from qgis.PyQt import QtCore
  File "/usr/lib/python2.7/dist-packages/qgis/PyQt/QtCore.py", line 28, in <module>
    sip.setapi(api, 2)
ValueError: API 'QDate' has already been set to version 1`
user: bl4k1st
labels: bug: Something isn't working as it's supposed to
issue_1417: state: open
title: python2-sip-pyqt4   package seems to be required
body:   we need a patch for checkdeps.py to make a user friendly statement like : find required package at https://gitlab.com/inemum/inemum_archlinux/raw/master/python2-sip-pyqt4/PKGBUILD 

else checkdeps.py might gain a reputation of being feckless ? see also [AUR](https://aur.archlinux.org/packages/pybitmessage/#comment-675147)

[link to Arch makepkg file](https://gitlab.com/inemum/inemum_archlinux/raw/master/python2-sip-pyqt4/PKGBUILD )
user: dimyme
labels: bug: Something isn't working as it's supposed to
issue_1409: state: open
title: Blind signatures as an alternate proof a message is not spam 
body: # Rationale
Underpowered devices (e.g. on ARM architecture) take very long to calculate the PoW. As time progresses, the difference in hashing capacity may diverge even further, some people unable to communicate with each other. This proposal provides an alternative method for proving a message is not spam, using blind signatures added to the protocol. The exact details will be updated as the proposal evolves.

**The purpose of the blind signatures isn't to replace the PoW mechanism, but to augment it, and to allow alternative method for accessing the network, for example by paying for the blind signatures. The payments can be used to finance the infrastructure and development.**

# TLDR;
The protocol will contain a parallel inventory of objects which are signed using blind signatures, instead of having a nonce for a PoW. A miner would be able to replace the blind signature with a nonce, allowing the object to be transferred to the "normal" inventory, providing backwards compatibility. If the blind signature was obtained against a payment, the miner can participate in the revenue.

If you're familiar with bitcoin, an analogy would be a permissioned unidirectioinal sidechain (or sidepool since Bitmessage has no chain), which can be used by people who for some reason are unable to use bitcoin directly. Even though this bitmessage "sidepool" doesn't have as strong censorship resistance, through the use of blind signatures, a high level of anonymity is achieved, allowing for censorship resistance to be maintained indirectly. Also, this is only unidirectional, used for sending new objects. For recipients, the miners would provide backwards compatibility and no change is necessary.

# Blind signatures
Blind signatures are a mechanism for certifier to authenticate data without knowing its content. A third party can then use the certifiers public key to verify that a particular piece of data was authenticated by them. An implementation based on pre-existing research, was created for pyelliptic for a bounty: https://bountify.co/blind-signature-library-in-python-or-c

# New object structure
Instead of the "nonce" at the beginning, the object would contain an array of signatures+pubkeys (with a leading varint indicating the depth). Here an example with 2 levels. The lowest level is always a signed inventory vector, and the highest is always the top-level certifier (CA). Mid-level certifiers are possible if they are needed for some reason. This part will probably be updated regarding pubkey structure (e.g. what curve is used etc).

1. depth - varint
2. lvl1sig - signature of the inventory vector
3. lvl1F - F (blinding factor)
4. lvl1pubkey - public key for the signature
5. lvl2sig - signature of the lvl1pubkey
6. lvl2F - F (blinding factor)
7. lvl2pubkey - pubkey of the certifier

# Routing
An object with signatures would use Dandelion-style routing to reach a miner. The miner would replace the signatures with a nonce, and inject the object into the normal inventory. Support for routing of signed objects would be indicated through a bit in the service bitfield.

# Usage
## Initialisation
The CA pubkey is distributed to all participants (e.g. in the code)

## Client preparation
Client sends a bunch of blinded pubkeys to the CA, who will sign them if certain criteria are fulfilled (e..g payment received) and the client unblinds them. This can happen over any protocol, e.g. through a PoW-ed object or through a new command in the protocol, with the client connecting directly to the CA node.

## Client sending a signed object
Client will pick a random pubkey, and blind-sign the object's inventory vector with it, attaching all the needed signatures and pubkeys to the signature block. Then it will use dandelion-type routing to send the object to the network.

## Validation
Unlike with e-cash, where double-spending is a problem, the client is motivated not to reuse pubkeys as that reduces their anonymity. So it isn't necessary for the validators (dandelion stem nodes and miners) to check if the pubkey is already used. The pubkeys could also contain some sort of expiration (e.g. a mid-level CA would be only valid for a particular month), so that the nodes don't need to keep track of old pubkeys forever. This partially reduces anonymity, but not much (one month should provide adequate granularity).

## Mining
The object will eventually hit a miner, who will replace the signature block with a nonce and inject it into the "normal" network. The nodes in the dandelion stem can compare new mined objects with the signed routed ones to see if it's still necessary to switch to the bloom phase, to prevent waste.

# Problems
Onion routing (ACKs) to a recipient who doesn't support the protocol will break in the current proposal (isn't backwards compatible). Therefore pubkey objects of addresses should indicate with a bitfield if they support blind signatures.
user: PeterSurda
labels: enhancement: New feature
developers: The issue is relevant mainly for developers rather than users
protocol: Protocol change
issue_1404: state: open
title: invbloom - New command for reduction of bandwidth
body: ## Reason
After the `version`/`verack` handshake, Bitmessage sends a list of all inventory vectors to the other side. This causes a huge amount of bandwidth wastage, in particular for nodes that accept inbound connections. The proposal is to add a new command `invbloom` which will reduce this step in synchronisation.

This issue will be updated with more specifics as time goes on.

## Data
After the command, there will be some metadata, and data. The bloom filter will use Murmurhash v3, just like Bitcoin's bloom filters. It's implemented in pybloomfiltermmap and it's very fast.

## When to use
The support for this command will be indicated by a new bitfield in the `version` command. If both sides support this bitfield, instead of sending the list of all inventory vectors (referred to as "biginv" in PyBitmessage source code), the two nodes will send an `invbloom`.

Since a bloom filter allows for false positives, the `invbloom` command should be issued periodically to reduce the probability that an object goes missing. The delay should use a Poisson probability and pick a random outbound connection (similarly to how Dandelion works).

## How to handle
Upon receiving `invbloom`, the node can send a list of inventory vectors that aren't in the bloom filter. This allows to reuse the rest of the protocol with no change.

## Further development
Additional improvements can be added in the future with further protocol changes.

## Anonymity
A different bloom filter should be used for each connection to prevent tracking of a node. I did tests with pybloomfilter and it looks like it isn't deterministic, so it probably isn't necessary to add random data to it.
user: PeterSurda
labels: enhancement: New feature
developers: The issue is relevant mainly for developers rather than users
protocol: Protocol change
issue_1394: state: open
title: UI refactoring, part 2
body: Hello!

In the second part of UI refactoring I moved most of widgets definitions into ui-files, removed autogenerated code and renamed `bitmessageui` to `main`.
Minor appearance differences include:
 * Add buttons are not resizing infinitely
 * ~~UPnP checkbox label on tab "Network Settings" of Settings dialog~~
 * ~~"Resends expire tab" of Settings dialog.~~

Also maybe I did wrong in `retranslateui`.

These changes definitely require testing. I'm going to write some soon. ~~But it may make sense to merge this before qt5-wip because of many pylint warnings in obsolete `settings` and `bitmessageui` modules.~~
user: g1itch
labels: enhancement: New feature
issue_1389: state: open
title: Porting bitmessageqt to Qt5
body: Hello!

I realized that column width problem in `QTableWidget` was actually the [Qt bug](https://bugreports.qt.io/browse/QTBUG-67131).

I mostly finished work in this branch though it still needs some testing.
user: g1itch
labels: enhancement: New feature
issue_1381: state: open
title: asyncore_pollchoose import refactor
body: src/network/asyncore_pollchoose.py could benefit from [changes like this](https://github.com/Bitmessage/PyBitmessage/commit/533df80ce98c40b0a2424ecc17bd395e0dbcdfa7) to imports, however it would imply importing errno directly which would require some refactoring of the file which is out of scope for the code_quality work which is already approved. This change was recommended by @g1itch 

This issue is to ensure such refactoring is considered at some point. 
user: coffeedogs
issue_1380: state: open
title: Asyncore poller efficiency
body: Asyncore pollers initialise the poller objects for every poll. This causes inefficiency when using a huge number of connections. It's only necessary to do it this way for the select poller, the others can reuse an old object. To fix this requires some refactoring, instead of performing a check and set/reset for every connection for every poll, the set/reset can be done when the write or read buffer get updated. This reduces the number of checks as well as syscalls. I managed to get a prototype working on one of the bootstrap servers, and it reduced the CPU usage of the asyncore loop by a factor of 6. However it needs more work as it was only done with the epoll poller, and I had to disable the bandwidth limit functionality.
user: PeterSurda
labels: enhancement: New feature
issue_1379: state: open
title: Network I/O buffer operations slow
body: Operations like `slice_write_buf`, `slice_read_buf`, ~~`append_write_buf`~~, ~~`read_buf.extend`~~ are slow because they copy data around and reallocate memory. There are several things which can be done to improve this without major refactoring:

- preallocate bytearray, `buffer = bytearray(max_size)`. This has some tradeoffs, e.g. more memory required, and removing data from the buffer then takes more time (so we need to avoid removing data from it).
- use `recv_into`/`recvfrom_into` instead of `recv`/`recvfrom`. These put data directly into the buffer rather than allocating new strings
- use memoryview instead of array slice when parsing data
- instead of slicing the front of the buffer, use some other method, e.g. using memoryview as well, see here: https://stackoverflow.com/questions/15962119/using-bytearray-with-socket-recv-into#15964489
- if we can somehow use a separate buffer for each command, we can avoid locking, allowing more CPU to be used on multi-core systems.

I ran some benchmarks, using bytearray slicing and appending has a performance of about 1MB/s, even when using bytearrays. Preallocating buffers can do about 20GB/s (20k times better), and using a slice of memoryview about 6GB/s (6k times better). Obviously it depends on other criteria, I was using 1kB chunks of data within the buffer.

Some operations don't work on buffers, e.g. you can't use a buffer slice as a dict key, but I think most of these have already been addressed earlier.

**Edit:** Appending to bytearrays doesn't seem to cause performance problems, only slicing from the beginning.
user: PeterSurda
issue_1373: state: open
title: No more prints
body: There are still occasions where `print` has remained and should be replaced by the `logger.*`. Some can remain, e.g. the notification about daemonizing or missing dependencies. This issue will be updated as I find more locations.

- [x] `src/api.py`
user: PeterSurda
issue_1361: state: open
title: Chan difficulty setting
body: Currently, PyBitmessage assumes chans have a difficulty of 1. It will use difficulty 1 when sending to a chan, and accepts difficulty of 1 when receiving a message to chan. Chans were probably conceived as a dirty hack without too much additional work necessary. Another reason why there isn't a difficulty adjustment for chans is that there is no consensus mechanism for chan members to agree on a single difficulty.

There are ongoing spam attacks, e.g. in the "bitmessage" an "general" chan, sending a couple of thousands messages per day. These attacks use a unique sender address for each message (or at least most of them), so they can't be blocked with a blacklist. I received requests for a countermeasure. There can probably be endless discussions about how to approach it, however the easiest one is to allow chans to have higher difficulty, with flexible minimum threshold that does not need to be agreed upon exactly, with the risk that in some cases some people will not receive all messages. People running older versions or alternative clients may also have problems sending messages to the chan (well, they will be able to send, just others may filter their messages). This may be acceptable during a spam attack. Over longer term, as people upgrade and the thresholds smooth out, it would become less of an issue.

My proposal is to allow chan members to increase a difficulty of a message sent to the chan if they think it's being spammed. The recipient will then see that a message with higher difficulty arrived, and use to to adjust the minimum acceptable difficulty using some formula, and will drop new messages with lower difficulty. At the same time it will know it needs to use a higher difficulty when sending messages as well. The exact formula is open for a debate. considering there is no consensus mechanism and the messages don't arrive in a particular order.

Requesting feedback.
user: PeterSurda
labels: enhancement: New feature
issue_1347: state: open
title: Slowdown when deleting in the UI
body: Deleting messages individually causes too much CPU usage. I narrowed it down to `propagateUnreadCount` in `src/bitmessageqt/__init__.py`. I remember doing performance tests, so it must have broken since then.
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_1345: state: open
title: bitmessage --curses  crashes over UTF / Unicode
body: ### the curses mode could use a lil fixing ...  then it works  great. happened after "reply-to-BM"

I ran v.0.6 tip 

```


2018-09-18  15:29:45,416 - CRITICAL - Unhandled exception Traceback (most recent call last):   File "bitmessagemain.py", line 507, in <module>     main()

  File "bitmessagemain.py", line 503, in main    mainprogram.start()

  File "bitmessagemain.py", line 398, in start    bitmessagecurses.runwrapper()

  File "/z/src/bitmessagecurses/__init__.py", line 1004, in runwrapper    curses.wrapper(run)

  File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper    return func(stdscr, *args, **kwds)

  File "/z/src/bitmessagecurses/__init__.py", line 1049, in run    handlech(stdscr.getch(), stdscr)

  File "/z/src/bitmessagecurses/__init__.py", line 334, in handlech    sendMessage(fromaddr, toaddr, ischan, subject, body, True)

  File "/z/src/bitmessagecurses/__init__.py", line 735, in sendMessage     r, t = d.inputbox("Message body", 10, 80, init=body)

  File "/usr/lib/python2.7/site-packages/dialog.py", line 2788, in inputbox     kwargs, strip_xdialog_newline=True, raw_help=True)

  File "/usr/lib/python2.7/site-packages/dialog.py", line 1748, in _widget_with_string_output
    code, output = self._perform(args, **kwargs)

  File "/usr/lib/python2.7/site-packages/dialog.py", line 1540, in _perform     **kwargs)

  File "/usr/lib/python2.7/site-packages/dialog.py", line 1301, in _call_program     cmdargs = self.dash_escape_nf(cmdargs)

  File "/usr/lib/python2.7/site-packages/dialog.py", line 1095, in dash_escape_nf     return _dash_escape_nf(args)

  File "/usr/lib/python2.7/site-packages/dialog.py", line 323, in _dash_escape_nf     l = _dash_escape(args[1:])

  File "/usr/lib/python2.7/site-packages/dialog.py", line 306, in _dash_escape     if arg.startswith("--"):

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 134: ordinal not in range(128)

```

I hate markdown btw
user: dimyme
labels: bug: Something isn't working as it's supposed to
issue_1316: state: open
title: checkdeps.py broken
body: ```
Traceback (most recent call last):
  File "checkdeps.py", line 142, in <module>
    if x in EXTRAS_REQUIRE_DEPS
KeyError: None
```
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_1306: state: open
title: Matrix connectivity
body: A bridge between Bitmessage and [Matrix](matrix.org). Here is corresponding issue in Matrix side:  https://github.com/turt2live/matrix-wishlist/issues/142.
user: homebeach
labels: enhancement: New feature
issue_1298: state: open
title: After user chooses "Quit" and allows Bitmessage to wait till sync is done, app can only be stopped via "kill"
body: When I press "Quit", PyBitmessage offers to wait till all the sync is done, then quit.

If I need to quit it anyway and click "Quit" again, nothing happens. The only means to kill the app at that moment is by using "kill" command (in my case, Ubuntu 16.04.4, only "kill -9" worked).

- [x] when closing using "File / Quit"
- [ ] when closing by closing the window
user: stayen
labels: bug: Something isn't working as it's supposed to
issue_1293: state: open
title: Menu labels continuity
body: It's common practice to add `...` to a menu label if it will not immediately perform an action or open a cancellable dialog.
See this example from Windows Explorer:

![image](https://user-images.githubusercontent.com/1301960/42119986-e3e7ca40-7c13-11e8-8aad-b0b1bcb8cad3.png)

Please do this in PyBitmessage too.
user: AyrA
issue_1284: state: open
title: New POW calculation module
body: For #1227. It's currently not connected to the PyBitmessage code, I'm going to get it done sooner or later.

It provides the `WorkProver` thread class which manages tasks and schedules them to solvers. There are 4 possible solvers:

- Single-threaded `DumbSolver` in Python. I optimised it so it now works ~2 times faster. In particular, I replaced `hashlib.sha512` with `SHA512` from OpenSSL. Since you need OpenSSL to assemble a message anyway, I think it's safe to use it in a fallback solver.

- Multiprocess based `ForkingSolver` in Python. It works faster too, because it relies on `DumbSolver`.

- Multithreaded `FastSolver` in C. I tried to utilize SIMD, but it gave very little speed up of 7 %, so it still calls OpenSSL.

- And `GPUSolver` in OpenCL.

The library was tested on a 4-core AMD64 Linux with integrated GPU and 45-CPU virtual machines with hyperthreading enabled:
- X86 Linux;
- AMD64 FreeBSD;
- AMD64 OpenBSD with the `bsd.mp` kernel;
- AMD64 NetBSD;
- AMD64 Windows 7.

I failed to install Hackintosh on QEMU, so somebody else has to test it there.
user: Kleshni
labels: enhancement: New feature
issue_1246: state: open
title: CLI option to specify logging level
body: It would be nice to have a command line option to specify or override log_level (debug/info/warning/error) at runtime. Useful when diagnosing transient issues like connectivity problems, object propagation etc. 
user: f97ada87
issue_1241: state: open
title: Address further fixes in bitmessagecli.py
body: Once all automated fixers have been implemented in the tools (superfluous-parens, E712), re-base, re-run the fixers then do these manual changes.

 * It seems os._exit() may be removed
 * Maybe os.path.join(directory, fileName) would be better than filePath = directory + '/' + fileName
 * Use with open() context manager where possible



user: coffeedogs
labels: bug: Something isn't working as it's supposed to
issue_1240: state: open
title: 'utf' should be 'utf-8'
body: @g1itch spotted in pybitmessagecli.py:

label   =    (jsonAddresses['addresses'][addNum]['label'  ]).encode('utf')              # may still misdiplay in some consoles

Should this be utf-8?
user: coffeedogs
labels: bug: Something isn't working as it's supposed to
issue_1237: state: open
title: handle_close / ReceiveQueue race condition
body: Came in bitmessage chan:

There is a race condition between the Asyncore thread and a ReceiveQueue thread where the Asyncore thread calls AdvancedDispatcher.handle_close (setting read_buf to an empty bytearray) between a ReceiveQueue thread ensuring the appropriate number of bytes in read_buf and calling the appropriate state_* method.

------------------------------------------------------
Hmm, I thought this was fixed. Let me check.

Peter

> Hi all,
> 
> Off the top of your head, any suggestions about the error below? Is
> it normal?
> 
> Bitmessage v.0.6 branch, Tor proxy, log level DEBUG.
> 
> May 03 09:56:31 Asyncore tcp.py@57 Outbound proxy connection to
> 85.114.135.102:8444
> May 03 09:56:31 ReceiveQueue_0 receivequeuethread.py@60 Error
> processing
> Traceback (most recent call last):
>   File "/opt/PyBitmessage/src/network/receivequeuethread.py", line
> 50, in run
>     connection.process()
>   File "/opt/PyBitmessage/src/network/advanceddispatcher.py", line
> 72, in process
>     if not cmd():
>   File "/opt/PyBitmessage/src/network/socks5.py", line 42, in
> state_auth_1
>     ret = struct.unpack('BB', self.read_buf[:2])
> error: unpack requires a string argument of length 2
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_1229: state: open
title: sqlite temporary storage path should point to PyBitmessage config directory
body: Mentioned in bitmessage chan. Needs to be checked if reproducible. Could be sqlite is createing a temp file in a different directory during VACUUM:


I got the following error while trying to start PyBM
_____________________________
ERROR: The msgpack package is not available.It is highly recommended for messages coding.
ERROR: If your package manager does not have this package, try running "pip install msgpack-python".
Loading config files from same directory as program.
Using default logger configuration
2018-05-02 08:53:07,236 - ERROR - /home/me/.namecoin/namecoin.conf unreadable or missing, Namecoin support deactivated
2018-05-02 08:53:13,627 - CRITICAL - (While VACUUM) Alert: Your disk or data storage volume is full. sqlThread will now exit.
______________________________
I really had very little free space in / partition
but actually I was running BM in portable mode in the /home partition which had 6 GiB free space.. so it should work..
I have just freed some space in / so I can start PyBM and send this message

Thanks
    NourEddineX
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_1227: state: open
title: POW improvements
body: I'm going to work on some improvements to the current POW subsystem:

- Continuously update expiry time while doing the work to hide your computing power from peers. Short living messages would also get advatage from this, because POW calculation can take notable part of their TTL.

- Calculate several POWs in parallel in the same thread. Previous change will require to periodically interrupt calculation, so we can interleave several POWs creating something like a simple task scheduler.

- Add ability to stop POW and cancel or edit a message in the UI.

- Add an expected time indicator to the UI, analogous to Vanitygen's.

- Make starting nonce random, solving this issue #1213.

What more?
user: Kleshni
labels: enhancement: New feature
issue_1225: state: open
title: API calls to work with raw objects
body: I think current API lacks 4 very useful methods:

- To list available object hashes for some criteria such as type, age, extra POW amount, some monotonous counter (like "rowid" from SQLite, possibly encrypted to hide internals from the API user).

- To get an object by its hash.

- To send a prepaired object. Current API has two similar methods, but they are undocumented and don't allow me to send objects of arbitrary type, only messages and public keys.

- Like previous, but with already calculated POW.

Their absense prevents using Bitmessage as a base for different protocols and extensions.

I can code them and make a pull request.
user: Kleshni
labels: enhancement: New feature
issue_1222: state: open
title: implement netcat operating mode
body: This PR enables a special headless operating mode (which I named "netcat" mode due to similarities with the Unix utility) where all object processing is disabled. Instead, raw objects received from the network are output to STDOUT unprocessed, also, any valid raw objects received on STDIN are broadcast to the network. 

This is a re-implementation of PR #1149 , using the switches defined in PR #1214 . The discussions from the linked PRs should provide useful background. 
user: f97ada87
labels: enhancement: New feature
issue_1215: state: open
title: More thorough testing mode
body: Instead of just sleeping for 30 seconds before shutdown, the testing mode should:

- [x] create a new random address
- [ ] send a message from that address to a testing address (TBD)
- [ ] wait until the ACK arrives (UISignaller queue can be used for this)
- [ ] show synchronisation progress and connection status every 10 seconds
- [ ] wait until synchronisation finishes
- [ ] change test mode description to explain it's for developers rather than end users
user: PeterSurda
labels: enhancement: New feature
developers: The issue is relevant mainly for developers rather than users
issue_1213: state: open
title: Nonce calculation random start value
body: If nonces are being tried from zero, the number of skipped matches could be used to guess the number of parallel hashers (e.g. the number of cores). Randomising the starting value should prevent this.

- [ ] safe PoW
- [ ] multiprocessing PoW
- [ ] C PoW
- [ ] OpenCL PoW
user: PeterSurda
issue_1187: state: open
title: coverage
body: setting up coverage for codacy is not so difficult. Even I got it to work. takes just 10 minutes to get going. tells percentage of code which is never run and tested by codacy. pls set it up so we know whats going on. :+1: 
user: sigoa
labels: developers: The issue is relevant mainly for developers rather than users
issue_1161: state: open
title: dontconnect not honoured
body: on a pristine install, if you modify PORTABLE mode and / or change NETWORK settings - say SOCKS5 settings back and forth - or  such - then pyBM (run from current v0.6 py sources in Linux) will **connect** even though initially DONTCONNECT is set in the KEYS.DAT file. This may be surprising or not desirable behaviour.

so if you really want DONTCONNECT, you have to pull the network cable, thus air-gapping the machine.

Peter says, he "cannot reproduce" it, so make of it what you want.    :+1: 
user: sigoa
labels: bug: Something isn't working as it's supposed to
issue_1155: state: open
title: Not all invs relayed
body: - it looks like if a connection is established, it does not relay all invs, although the initial "big inv" seems to work correctly. You can reproduce it by using a trustedpeer, and after a couple of hours restart, new objects will show up for syncing
- ACKs sent via Dandelion don't seem to enter stem phase correctly
- it could also affect locally created objects
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_1147: state: open
title: Tray Icon color, inconsistent state
body: This came in the bitmessage chan:

hello!
since last update the tray icon is always red, independently if there are connections. The icon in the main window correctly shows yellow. 

And another issue that I see sometimes, also with former version:
- I visit the lists of new messages and read and/or delete all of them
- new messages: 0
restart Bitmessage
- the line "new" is bold and an old number is listed beside
- when I click on "new" the list is empty, and the state is corrected
user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_1136: state: open
title: Bitmessage project looking for auditors/security experts
body: Details on reddit: https://www.reddit.com/r/bitmessage/comments/7xrb80/bitmessage_project_looking_for_auditors_andor/
user: PeterSurda
labels: developers: The issue is relevant mainly for developers rather than users
issue_1132: state: open
title: Is there a CVE record for the vulnerability?
body: Here https://github.com/Bitmessage/PyBitmessage/releases/tag/v0.6.3 you said that the release fixes vulnerabilities without the CVE number. On FreeBSD we have VulnXML where the vulnerabilities are entered, but you mentioned no CVE number.

Could you please add a CVE record for it, or update the log with the record?

user: yurivict
issue_1130: state: open
title: GPG Sign the binary releases
body: There is currently no way to verify that the released binary packages are in fact released by the developer. One way to do this is to sign the packages with GNUPG/PGP. There is an automated script to do this for github users, here: https://github.com/NicoHood/gpgit

Doing so helps prevent MITM attacks/malware from spreading. Thank you.
user: gitbugged
labels: enhancement: New feature
issue_1107: state: open
title: bitmsghash.cpp : printf("Number of threads: %i\n", (int)numthreads);
body: bitmsghash.cpp :
line 124 : printf("Number of threads: %i\n", (int)numthreads);

I suggest adding a bit more information in the printf field, at least a datetime, in order to have this printing a bit more useful.
Maybe it could also be written in the debug.log file ?

Thanks
Harry

user: ghost
labels: enhancement: New feature
issue_1039: state: open
title: GitHub release cycle
body: Could you make release here on GitHub a bit more frequent so that distributions can include updates sooner?
user: baimafeima
labels: enhancement: New feature
issue_1035: state: open
title: CLI Command Line Arguments
body: - [ ] Daemon command line argument
- [ ] Portable Mode command line argument
- [ ] BITMESSAGE_HOME environment variable

Daemon and Portable Mode should be command line arguments. This allows other programs to use the CLI much easier.
user: Lvl4Sword
labels: enhancement: New feature
issue_1015: state: open
title: Session-less forward secrecy and cryptographic deniability using Triple Diffie-Hellman
body: I would like to start a discussion how to change (or extend) current encryption protocol so we can use short therm ephemeral keys. This leads to a better security in an event of the long term key compromise.

I propose, that we can create new `pubkey` object version which will contain long term key bundled with the short term session key, and publish this object to the network more frequently. Everyone can then create ephemeral key and compose a message based on the information already available on the network. The only requirements is, that the recipient must cache private parts for some time.

My textbook example using BM pyelliptic:  
```

import hashlib
import pyelliptic

'''
Bob's identity key IKB
Bob's signed prekey SPKB
Bob's prekey signature Sig(IKB, Encode(SPKB))
'''

# This should be in the Pubkey message broadcasted by Bob
IKB = pyelliptic.ECC(curve='sect571r1')  # Bob's identity key
SPKB = pyelliptic.ECC(curve='sect571r1') # Bob's signed prekey
SigSPKB =  IKB.sign(SPKB.get_pubkey())  # prekey signature

# Alice keys
# Alice verifies the prekey signature and aborts the protocol if verification fails.
# Alice then generates an ephemeral key pair with public key EKA.
IKA = pyelliptic.ECC(curve='sect571r1') # Alice's identity key
EKA = pyelliptic.ECC(curve='sect571r1') # Alice's ephemeral key

'''
Alice compute shared secret SK (with mutual authentification, as a result of IKA, IKB usage):
DH1 = DH(IKA, SPKB)
DH2 = DH(EKA, IKB)
DH3 = DH(EKA, SPKB)
SK = KDF(DH1 || DH2 || DH3)
'''

DHA1 = IKA.get_ecdh_key(SPKB.get_pubkey())
DHA2 = EKA.get_ecdh_key(IKB.get_pubkey())
DHA3 = EKA.get_ecdh_key(SPKB.get_pubkey())
SKA = hashlib.sha256(DHA1 + DHA2 + DHA3)
print 'Alice has:',  SKA.hexdigest()

# Bob compute
DHB1 = SPKB.get_ecdh_key(IKA.get_pubkey())
DHB2 = IKB.get_ecdh_key(EKA.get_pubkey())
DHB3 = SPKB.get_ecdh_key(EKA.get_pubkey())
SKB = hashlib.sha256(DHB1 + DHB2 + DHB3)
print 'Bob has:',  SKB.hexdigest()

# use SKA( == SKB) key as usual
```
For more info on this protocol, check [https://whispersystems.org/docs/specifications/x3dh/](https://whispersystems.org/docs/specifications/x3dh/)

Bitmessage is by nature async protocol, so we should use this kind of construction instead of session based, like proposed in  https://www.reddit.com/r/bitmessage/comments/3zzevp/forward_secrecy_for_bitmessage/ and https://bitmessage.org/forum/index.php/topic,2981.0.html
(which are also interesting!)

This will solve the issues #563 #454  
If somebody wants to test this, we should start collecting dependencies.
user: viralpoetry
labels: enhancement: New feature
protocol: Protocol change
issue_1010: state: open
title: feature: find "important" messages easier
body: I am losing the overview a little in BM

e.g. currently I see only as ways for me: 
* marking as unread (but this read-status can be lost again) or 
* saving to a file (which brings me outside of BM)

e.g. I'd like to mark a message with a certain tag (so I could later find all those mails with tags) or move to a special folder in the messages UI

user: Erkan-Yilmaz
labels: enhancement: New feature
issue_1009: state: open
title: feature: send message from messages tab
body: I'm missing a "send message" option from messages UI

* e.g. my experience from the messages tab (where I am most of the time): right click on address shows: New
  * I instinctively think/thought that I can compose with that a new message to that address



user: Erkan-Yilmaz
labels: enhancement: New feature
issue_1003: state: open
title: "BitMessage Secure Station" open-hardware open-core project
body: We are working on the development of a simple open-hardware dedicated platform, the "BitMessage Secure Station", that will allow BitMessage users to reach military grade anonymity and privacy protection : The biggest mistake (We call it betrayl) of all the security/privacy free tools developpers is that they never want to take in consideration that their tools would work well on a perfect secure non backdoored and non backdoorable / compromizable computer, which don't exist yet.

And here I am clearly refering to the most important things Edward Snowden reminded us : "Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it." (Edward Snowden)

Indeed, this project we are developping is aiming at solving the best as we can (Military grade) the issues Snowden perfectly described and reminded us about End-Points (Computers) weaknesses when connected to the internet, and we do it radicaly using the best state of the art known technics, consisting in using a double-computer architecture :

The draft "BitMessage Secure Station" hardware is detailed here (Used for BitMessage software developpers as an early 'simple version SDK) : 

http://picpaste.com/BitMessageSecureStation-gYTXbL2l.png

The final "BitMessage Secure Station" hardware architecture being here :

http://picpaste.com/BitMessage_Secure_Station_V2-MWbERDLf.png

The overall cost of a full "BitMessage Secure Station" should be less than 100€, accessible to everybody. We encourage other P2P applications developers to port their own software project to the BitMessage Secure Station hardware, and we are willing to help and support all those that will plan to do it. Please do not hesitate to contact us.

As you will understand, this add-on project is not about, at least for the moment, doing any major change to the BitMessage software, but to create a dedicated hardware that solves security issues that cannot be solved by software with a "Mono-processor" architecture : In the architecture we are designing, we are using a 2 microprocessors + 1 microcontroller model :

• A first computer (Low cost Raspberry Pi, accessible to everybody for 30$) connected to the internet, that must considered compromised.

• A second computer (Low cost Raspberry Pi) fully air gapped from the internet, you will use this one to read/enter your messages securely.

The drivers for the SPI Port handling on both Raspberry Pi will be developed in C, for Raspbian OS, so that Peter Surda can easily integrate then to the PyBitMessage software written in Python.

• Interconnectiong both with an SPI synchrone serial port, but for added security, this serial port goes through a "Firewall", acting as the "Secure Element" of the overall system (Made out of a PIC 24 micro-controller), that will check & filter any kind of side channels attackers could try to build over our dedicated protocol over the SPI serial port, by ensuring the protocol defined for transferring data between the 2 computers is strictly respected, filtering at the same time all time-based side channels on the SPI serial port. 

• The PIC 24 Micro-controller handling two SPI serial ports and relayings data between each port bidirectionnaly, with its software highly secured (coded 100% in assembly language, with no OS and no LIBC libraries used, just handling interrupt routines and a few timers to make the secure element / firewall work). 

In the definitive version of the PCB, the PIC 24 Micro-controller will be replaced by a Xilinx Spartan 6 LX 9 FPGA, to implement a custom free and open non-backdoored microprocessor in the FPGA, and we will also take advantage of this FPGA to build our own hardware RNG that will be used by the Air-Gapped Raspberry Pi, integrating Cryptech open core FPGA based hardware RNG with two distincts entropy sources. In a final version, for added security, we will replace the FPGA based custom microprocessor + its software in assembly language by a new design where we will implement all those functionnalities made by software on this custom FPGA based microprocessor, by the equivalent fully hardcoded into the FPGA in the form of finite state machines, reaching above military grade security because there is no more processor and no more software running, having therefore an true software attack surface prooven null.

At BitMessage software level, we are going to split the BitMessage software into two parts, one part running on the "non secure" Raspberry Pi, mainly handling all the P2P network connections and data broadcast throught the P2P network, and holding a new "CIPHERED-MESSAGES.DAT", while the second "Secure Air-Gapped" Raspberry Pi will hold all those important files (KEYS.DAT, and eventually a CLEAR-TEXT-MESSAGES.DAT caching the CIPHERED-MESSAGES.DAT but deciphered), and we will manage all cryptographic functions and end-user GUI. 

We are working with Peter Surda on how to adapt the BitMessage software to this "splitted" architecture in the most efficient way.

With the BitMessage Secure Station, we are simply taking in account the best state of the art knowledge in defensive cyber security & crypto-anarchist tricks in order to build an "hardened end-point", that can resist "NSA & friends" or "competitors" grade military attacks, therefore truly and proovenly protecting you from :

► Keyloggers malware protection :

It is achieved architecturaly by having a double processor system, with one computer being compromized and connected to the internet, and another one air-gapped and not connected to the internet : The messages in clear text are being entered on the computer not connected to the internet : Assuming that there is no side channel or hidden channel on the serial port connecting the two processors (Will be discussed below), even if there is a keylogger installer on the air gapped computer, it will not be able to transfer its data if we can ensure there is no side channel or hidden channels between the two computers.

► Keyescrow malware protection (Protection of KEYS.DAT and MESSAGES.DAT):

Same as above. (Prevent the private keys used by BitMessage from being stolen by agencies/hackers)

► Hardware integrated circuits serial numbers fingerprinting identification technic protection when using TOR or VPNs :

This problem is solved by dedicating a new hardware for the first computer, connected to the internet and that will be compromized, whose serial numbers where never associated to the user identity before : A brand new Raspberry Pi bought in cash in an electronic store is the perfect way to achieve this. It also mean dedicating this hardware exclusively for this usage, and never connect to it any device : 

Exemple : 

Never connect USB Flashdisc key to it, whose serial number, already associated to the user's identity, to it, because it would allow to extrapolate the identity to associate to the Raspbery serial number to the identity already associated with the USB Flashdisc key. Same thing for LCD screen : They transmit serial number (VGA, DVI, or HDMI) to the graphic card, and can have the same terrible effect as a USB flashdisc key.

We will have to give the user a list I have already been working on for years, of all the parts or subsystems known in a computer to have serial numbers. 

Let's say this issue is a matter of respecting a strict security procedure.

► Hardware characteristics (Speed of each processor analysis) fingerprinting identification technic protection when using TOR or VPNs :

Same as above.

► Keystroke timing fingerprinting identification technic protection when using TOR or VPNs :

This problem is solved architecturaly exactly like the Keylogger protection above.

► Phrasing and wording fingerprinting identification technic protection when using TOR or VPNs :

We can use a trick many hackers know, and implement a kind of wording and rephrasing system : Using a translator for exemple, from english to french, and back french to english.... But there are other programs that do exist and to the job, There are many ways to do it indeed.

This issue is also solved architecturaly as the Keylogger protection mecanism described above. 

► Side channel & hidden channels protection between the first and the second computers, interconnected through a serial port :

This problem is solved by inserting a microcontroller having two serial ports, on the serial link between the two computers :
If the technic of using two microprocessor connected with a serial port that offers the lowest attack surface possible, it can be improved greatly inserting a microcontroller that will do the following :

• Check that the little protocol we will have to invent and implement (And design as much hidden channel proof as possible) is correctly implemented, and that no other unwanted data are transmitted on the serial link.
• Fight the timing side channel attack surface on the serial port : Serial ports offer the lowest attack surface regarding side & hidden channels, but it is still vulnerable to timing-between-each-byte-sent-on-the-serial-port side channel. The microcontroller code can "filter" these timings by buffering and normalizing them. Time based side channels are well known, and must be & can be fighted.

As you see, when we where talking about giving you true crypto-anarchist tools reaching military grade security, we were not laughting at you, we were very serious about this.
We had enough bullshit driven by FEDS worldwide. We perfectly know were most of the problems are : End-Point weaknesses.

And we decided to solve it for BitMessage. BitMessage being already one of the best Crypto-Anarchist communication tool available, but as all other "good" tools, if they are running on comprimized weak end-point, it's USELESS.

The "BitMessage Secure Station" Open-hardware project is being discussed on the Crypto-Anarchist Federation channel on BitMessage :

Chan name : Crypto-Anarchist Federation
Chan address : BM-2cWdaAUTrGZ21RzCpsReCk8n86ghu2oY3v

Contacts if you want to participate or support :

Peter Surda BitMessage Software Core Developper BM Address :
BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm

Stman BitMessage Secure Station open-hardware Core Developper BM Address : 
BM-2cWZW87PJN5VZjtJCpk3hXcYefhNCxdjU6

BitCoin donations for the "BitMessage Secure Station" open-hardware prototypes development : 
1DnEzQvKb7hzgmfAwP1oFU9WQEDBHCqFRM

For the first Beta Version of the PCB, we are planning to build 10 prototypes that will be sent in priority to those collaborating to the project.
user: stman
labels: enhancement: New feature
issue_953: state: open
title: Move from SHA1 to SHA256
body: Recently the team at Google have found the first SHA1 collision,
the ECDSA signatures use SHA1 and most of the code for a switch to SHA256 is in the comments already.

https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

- [x] allow signing with SHA256 for people who want to experiment
- [ ] make all signatures SHA256
- [ ] disable support for SHA1 verification
user: kewde
labels: enhancement: New feature
issue_943: state: open
title: Integrating Kovri? 
body: It seems like it could be valuable to integrate Kovri, which is a C++ version of I2P being built by the Monero developers. 

This could help hide from where the messages are originating and limit the ability of correlation attacks.   

https://github.com/monero-project/kovri

user: CameronRuggles
labels: enhancement: New feature
issue_901: state: open
title: CSS support for HTML-Messages
body: I don't know if Bitmessage supports CSS but I wasn't able to use CSS in my messages, neither with `<link>` nor with `<style>` or inline-CSS. A native CSS implementation would be very nice to have.

user: NexAdn
labels: enhancement: New feature
issue_897: state: open
title: [Security] Update to PyQt5
body: As you know Qt4 is no longer receiving security updates, you should switch to Qt5 and its python bindings.
The switch from pyqt4 to pyqt5 should be relatively easy according to pyqt documentation on this topic (for example [here](http://pyqt.sourceforge.net/Docs/PyQt5/pyqt4_differences.html)).

user: ghost
labels: enhancement: New feature
issue_886: state: open
title: Clarification on backport of pyelliptic requested + external dependency unbundling
body: As I work for a GNU system which unbundles where possible, I'd like to get some more
clarification on the backporting of pyelliptic you do. Can you explain your changes or point
out in the code which changes are made?

At your choice, could you even move the external dependencies
into git-submodules (other repositories) so it can be up to package
maintainers to pull them in?

This would improve the work of us package maintainers in cutting down the lines of code, especially for package systems like GNU Guix or systems like Gentoo.
https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
http://dustycloud.org/misc/talks/guix/chicagolug_2015/guix_talk.html (could include reasons and understanding, there are very likely more insights in https://www.gnu.org/software/guix/help/#papers and https://www.gnu.org/software/guix/help/#talks (same page))

user: ghost
issue_881: state: open
title: [feature suggestion] Basic Regex Filtering / Spam Filter
body: With the increasing number of the random digit posts, I think it's evident PyBitmessage could benefit from some sort of filter to help ignore these spammy messages on the client side that's user configured.

The easiest implementation I can think of is a text file in the config directory that lists regular expressions on each line to apply to incoming messages to ignore them. This would be up to the user to configure manually.

While it would be more work, it would be nice to see this feature in the GUI Blacklist tab, when you click the "Add new entry" button. Or a new "Spam" folder in the Messages -> Identities pane that would redirect these messages similar to most email clients.

I think most people could come up with even more user friendly functionality, but hopefully the first suggestion (with a config file) can demonstrate this is feasible even at the most rudimentary level.

user: beyondmeh
labels: enhancement: New feature
issue_878: state: open
title: Chan address in addressbook minor issues
body: Reported over BM

> 1) There is two chans: 2cW67GEKkHGonXKZLCzouLLxnLym3azS8r and
> 2DAV89w336ovy6BUJnfVRD5B9qipFbRgmr with name "general".
> 2) When connected I knew only one of it thought
> 2DAV89w336ovy6BUJnfVRD5B9qipFbRgmr was a person with his own name,
> say "John Doe".
> 3) I've added 2DAV89w336ovy6BUJnfVRD5B9qipFbRgmr to the address
> book.
> 4) Then some guy posted list of chans and I've added
> 2DAV89w336ovy6BUJnfVRD5B9qipFbRgmr to a chans list.
> 5) Then figured out it wasn't a person and tried to delete it from
> an address book or rename
> 6) After restarting Bitmessage it was restoring in the address book
> 7) Deleted from addressbook deleted from chans, added to chans,
> problem has gone.

So basically if an address is both in the addressbook and in chan, you can't delete it from the addressbook.

user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_877: state: open
title: bitmessagecli crashes when trying to send and you have no own addresses
body: python2 bitmessagecli.py
send
M
BM-[some-address]
//error

---

```
Would you like to send a (M)essage or (B)roadcast?
> M

What is the To Address?
> BM-[some-address]

     Using the only address in the addressbook to send from.

Traceback (most recent call last):
  File "/data/data/com.termux/files/home/PyBitmessage/src/bitmessagecli.py", line 1778, in <module>
    main()
  File "/data/data/com.termux/files/home/PyBitmessage/src/bitmessagecli.py", line 1773, in main
    UI((raw_input('>').lower()).replace(" ", ""))
  File "/data/data/com.termux/files/home/PyBitmessage/src/bitmessagecli.py", line 1348, in UI
    main()
  File "/data/data/com.termux/files/home/PyBitmessage/src/bitmessagecli.py", line 1773, in main
    UI((raw_input('>').lower()).replace(" ", ""))
  File "/data/data/com.termux/files/home/PyBitmessage/src/bitmessagecli.py", line 1492, in UI
    sendMsg(null,null,null,null)
  File "/data/data/com.termux/files/home/PyBitmessage/src/bitmessagecli.py", line 807, in sendMsg
    fromAddress = jsonAddresses['addresses'][0]['address']
IndexError: list index out of range
```

---

the same with broadcasts.

user: Musickiller
labels: bug: Something isn't working as it's supposed to
issue_865: state: open
title: Identities pane should remember collapsed/expanded configuration
body: I have several identities when I prefer to keep collapsed. When I close bitmessage and restart it, all of the identities are expanded again and I have to collapse them all once again.

Can bitmessage remember this configuration for restarts? Also, a collapse all and expand all identities might be nice too.

user: dmp1ce
labels: enhancement: New feature
issue_863: state: open
title: Wording of "Create a chan": "currently very likely that they will be the same chan" needs to be changed to "it will be the same chan"
body: I think this is deterministic, not just "very likely".

user: yurivict
labels: enhancement: New feature
issue_861: state: open
title: Can't Build RPM on f23
body: Trying to build RPM package on Fedora 23. As far as I can tell all deps are installed. A lot of this is Greek to me. It is not building RPM and I do not know why.

I installed packagemonkey first. Here is terminal output (minus the yum/dnf stuff):

```
[root@localhost bitmessagetest]# ./rpm.sh 
sed: can't read puppypackage/pinstall.sh: No such file or directory
sed: can't read puppypackage/puninstall.sh: No such file or directory
sed: can't read debian/*.links: No such file or directory
rm -f pybitmessage \#* \.#* gnuplot* *.png debian/*.substvars debian/*.log
rm -fr deb.* debian/pybitmessage rpmpackage/`uname -m`
rm -f ../pybitmessage*.deb ../pybitmessage*.changes ../pybitmessage*.asc ../pybitmessage*.dsc
rm -f rpmpackage/*.src.rpm archpackage/*.gz archpackage/*.xz
rm -f puppypackage/*.gz puppypackage/*.pet slackpackage/*.txz
mv: cannot stat ‘../pybitmessage’: No such file or directory
tar: Removing leading `../' from member names
tar: ../pybitmessage-0.4.4: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
mv: cannot stat ‘../pybitmessage-0.4.4’: No such file or directory
error: File /root/rpmbuild/SOURCES/pybitmessage_0.6.0.orig.tar.gz: No such file or directory
cp: cannot stat ‘/root/rpmbuild/RPMS/x86_64/pybitmessage*’: No such file or directory
cp: cannot stat ‘/root/rpmbuild/SRPMS/pybitmessage*’: No such file or directory
[root@localhost bitmessagetest]#
```

Then I tried again by recopy of the project from scratch:

```
[root@localhost pybitmessage]# ./rpm.sh 
sed: can't read puppypackage/pinstall.sh: No such file or directory
sed: can't read puppypackage/puninstall.sh: No such file or directory
sed: can't read debian/*.links: No such file or directory
Yum command has been deprecated, redirecting to '/usr/bin/dnf groupinstall Development Tools'.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run:
'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate'

Failed loading plugin: spacewalk
Failed to synchronize cache for repo 'thozza-XMind', disabling.
Failed to synchronize cache for repo 'galileo-sendEmail', disabling.
Failed to synchronize cache for repo 'rnons-mikidown', disabling.
Last metadata expiration check: 1:05:47 ago on Thu May 12 21:21:56 2016.
Group 'Development Tools' is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!
Yum command has been deprecated, redirecting to '/usr/bin/dnf install rpmdevtools'.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run:
'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate'

Last metadata expiration check: 1:07:49 ago on Thu May 12 21:21:56 2016.
Package rpmdevtools-8.6-2.fc23.noarch is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!
rm -f pybitmessage \#* \.#* gnuplot* *.png debian/*.substvars debian/*.log
rm -fr deb.* debian/pybitmessage rpmpackage/`uname -m`
rm -f ../pybitmessage*.deb ../pybitmessage*.changes ../pybitmessage*.asc ../pybitmessage*.dsc
rm -f rpmpackage/*.src.rpm archpackage/*.gz archpackage/*.xz
rm -f puppypackage/*.gz puppypackage/*.pet slackpackage/*.txz
tar: Removing leading `../' from member names
../pybitmessage-0.4.4/
../pybitmessage-0.4.4/generate.sh
../pybitmessage-0.4.4/LICENSE
../pybitmessage-0.4.4/INSTALL.md
../pybitmessage-0.4.4/arch.sh
../pybitmessage-0.4.4/src/
../pybitmessage-0.4.4/src/protocol.pyc
../pybitmessage-0.4.4/src/bitmessageqt/
../pybitmessage-0.4.4/src/bitmessageqt/messagecompose.pyc
../pybitmessage-0.4.4/src/bitmessageqt/emailgateway.py
../pybitmessage-0.4.4/src/bitmessageqt/about.ui
../pybitmessage-0.4.4/src/bitmessageqt/addaddressdialog.py
../pybitmessage-0.4.4/src/bitmessageqt/iconglossary.ui
../pybitmessage-0.4.4/src/bitmessageqt/blacklist.ui
../pybitmessage-0.4.4/src/bitmessageqt/emailgateway.pyc
../pybitmessage-0.4.4/src/bitmessageqt/about.pyc
../pybitmessage-0.4.4/src/bitmessageqt/emailgateway.ui
../pybitmessage-0.4.4/src/bitmessageqt/regenerateaddresses.py
../pybitmessage-0.4.4/src/bitmessageqt/widgets.pyc
../pybitmessage-0.4.4/src/bitmessageqt/newaddresswizard.pyc
../pybitmessage-0.4.4/src/bitmessageqt/dialogs.pyc
../pybitmessage-0.4.4/src/bitmessageqt/__init__.pyc
../pybitmessage-0.4.4/src/bitmessageqt/dialogs.py
../pybitmessage-0.4.4/src/bitmessageqt/__init__.py
../pybitmessage-0.4.4/src/bitmessageqt/regenerateaddresses.ui
../pybitmessage-0.4.4/src/bitmessageqt/messageview.pyc
../pybitmessage-0.4.4/src/bitmessageqt/iconglossary.pyc
../pybitmessage-0.4.4/src/bitmessageqt/settings.pyc
../pybitmessage-0.4.4/src/bitmessageqt/languagebox.pyc
../pybitmessage-0.4.4/src/bitmessageqt/newchandialog.ui
../pybitmessage-0.4.4/src/bitmessageqt/retranslateui.pyc
../pybitmessage-0.4.4/src/bitmessageqt/help.ui
../pybitmessage-0.4.4/src/bitmessageqt/newchandialog.pyc
../pybitmessage-0.4.4/src/bitmessageqt/support.pyc
../pybitmessage-0.4.4/src/bitmessageqt/messageview.py
../pybitmessage-0.4.4/src/bitmessageqt/retranslateui.py
../pybitmessage-0.4.4/src/bitmessageqt/connect.ui
../pybitmessage-0.4.4/src/bitmessageqt/settings.ui
../pybitmessage-0.4.4/src/bitmessageqt/newaddressdialog.pyc
../pybitmessage-0.4.4/src/bitmessageqt/bitmessageui.ui
../pybitmessage-0.4.4/src/bitmessageqt/widgets.py
../pybitmessage-0.4.4/src/bitmessageqt/bitmessage_icons_rc.py
../pybitmessage-0.4.4/src/bitmessageqt/settingsmixin.py
../pybitmessage-0.4.4/src/bitmessageqt/networkstatus.pyc
../pybitmessage-0.4.4/src/bitmessageqt/bitmessage_icons_rc.pyc
../pybitmessage-0.4.4/src/bitmessageqt/settingsmixin.pyc
../pybitmessage-0.4.4/src/bitmessageqt/foldertree.pyc
../pybitmessage-0.4.4/src/bitmessageqt/account.pyc
../pybitmessage-0.4.4/src/bitmessageqt/newsubscriptiondialog.pyc
../pybitmessage-0.4.4/src/bitmessageqt/newaddressdialog.py
../pybitmessage-0.4.4/src/bitmessageqt/networkstatus.py
../pybitmessage-0.4.4/src/bitmessageqt/specialaddressbehavior.ui
../pybitmessage-0.4.4/src/bitmessageqt/bitmessage_icons.qrc
../pybitmessage-0.4.4/src/bitmessageqt/utils.pyc
../pybitmessage-0.4.4/src/bitmessageqt/messagecompose.py
../pybitmessage-0.4.4/src/bitmessageqt/bitmessageui.py
../pybitmessage-0.4.4/src/bitmessageqt/addaddressdialog.ui
../pybitmessage-0.4.4/src/bitmessageqt/specialaddressbehavior.pyc
../pybitmessage-0.4.4/src/bitmessageqt/specialaddressbehavior.py
../pybitmessage-0.4.4/src/bitmessageqt/about.py
../pybitmessage-0.4.4/src/bitmessageqt/migrationwizard.py
../pybitmessage-0.4.4/src/bitmessageqt/uisignaler.pyc
../pybitmessage-0.4.4/src/bitmessageqt/newchandialog.py
../pybitmessage-0.4.4/src/bitmessageqt/safehtmlparser.pyc
../pybitmessage-0.4.4/src/bitmessageqt/connect.py
../pybitmessage-0.4.4/src/bitmessageqt/connect.pyc
../pybitmessage-0.4.4/src/bitmessageqt/regenerateaddresses.pyc
../pybitmessage-0.4.4/src/bitmessageqt/settings.py
../pybitmessage-0.4.4/src/bitmessageqt/help.py
../pybitmessage-0.4.4/src/bitmessageqt/blacklist.py
../pybitmessage-0.4.4/src/bitmessageqt/languagebox.py
../pybitmessage-0.4.4/src/bitmessageqt/newaddresswizard.py
../pybitmessage-0.4.4/src/bitmessageqt/migrationwizard.pyc
../pybitmessage-0.4.4/src/bitmessageqt/help.pyc
../pybitmessage-0.4.4/src/bitmessageqt/iconglossary.py
../pybitmessage-0.4.4/src/bitmessageqt/utils.py
../pybitmessage-0.4.4/src/bitmessageqt/bitmessageui.pyc
../pybitmessage-0.4.4/src/bitmessageqt/foldertree.py
../pybitmessage-0.4.4/src/bitmessageqt/blacklist.pyc
../pybitmessage-0.4.4/src/bitmessageqt/newsubscriptiondialog.ui
../pybitmessage-0.4.4/src/bitmessageqt/uisignaler.py
../pybitmessage-0.4.4/src/bitmessageqt/networkstatus.ui
../pybitmessage-0.4.4/src/bitmessageqt/newsubscriptiondialog.py
../pybitmessage-0.4.4/src/bitmessageqt/addaddressdialog.pyc
../pybitmessage-0.4.4/src/bitmessageqt/wanlan.ui
../pybitmessage-0.4.4/src/bitmessageqt/addpeer.ui
../pybitmessage-0.4.4/src/bitmessageqt/support.py
../pybitmessage-0.4.4/src/bitmessageqt/account.py
../pybitmessage-0.4.4/src/bitmessageqt/safehtmlparser.py
../pybitmessage-0.4.4/src/bitmessageqt/newaddressdialog.ui
../pybitmessage-0.4.4/src/defaultKnownNodes.pyc
../pybitmessage-0.4.4/src/api.pyc
../pybitmessage-0.4.4/src/helper_inbox.pyc
../pybitmessage-0.4.4/src/l10n.pyc
../pybitmessage-0.4.4/src/class_singleCleaner.py
../pybitmessage-0.4.4/src/defaultKnownNodes.py
../pybitmessage-0.4.4/src/debug.pyc
../pybitmessage-0.4.4/src/helper_threading.pyc
../pybitmessage-0.4.4/src/class_objectProcessor.pyc
../pybitmessage-0.4.4/src/depends.py
../pybitmessage-0.4.4/src/protocol.py
../pybitmessage-0.4.4/src/class_sqlThread.pyc
../pybitmessage-0.4.4/src/helper_bitcoin.pyc
../pybitmessage-0.4.4/src/helper_inbox.py
../pybitmessage-0.4.4/src/bitmessagemain.py
../pybitmessage-0.4.4/src/class_receiveDataThread.pyc
../pybitmessage-0.4.4/src/singleton.py
../pybitmessage-0.4.4/src/class_singleCleaner.pyc
../pybitmessage-0.4.4/src/class_objectHashHolder.py
../pybitmessage-0.4.4/src/compiletest.py
../pybitmessage-0.4.4/src/namecoin.py
../pybitmessage-0.4.4/src/class_outgoingSynSender.pyc
../pybitmessage-0.4.4/src/sslkeys/
../pybitmessage-0.4.4/src/sslkeys/key.pem
../pybitmessage-0.4.4/src/sslkeys/cert.pem
../pybitmessage-0.4.4/src/qidenticon.pyc
../pybitmessage-0.4.4/src/shared.pyc
../pybitmessage-0.4.4/src/helper_startup.pyc
../pybitmessage-0.4.4/src/tr.pyc
../pybitmessage-0.4.4/src/class_receiveDataThread.py
../pybitmessage-0.4.4/src/build_osx.py
../pybitmessage-0.4.4/src/class_addressGenerator.pyc
../pybitmessage-0.4.4/src/class_singleWorker.py
../pybitmessage-0.4.4/src/class_objectProcessorQueue.pyc
../pybitmessage-0.4.4/src/class_singleListener.pyc
../pybitmessage-0.4.4/src/upnp.py
../pybitmessage-0.4.4/src/highlevelcrypto.py
../pybitmessage-0.4.4/src/addresses.pyc
../pybitmessage-0.4.4/src/namecoin.pyc
../pybitmessage-0.4.4/src/shared.py
../pybitmessage-0.4.4/src/helper_threading.py
../pybitmessage-0.4.4/src/singleton.pyc
../pybitmessage-0.4.4/src/socks/
../pybitmessage-0.4.4/src/socks/LICENSE
../pybitmessage-0.4.4/src/socks/__init__.pyc
../pybitmessage-0.4.4/src/socks/__init__.py
../pybitmessage-0.4.4/src/socks/README
../pybitmessage-0.4.4/src/socks/BUGS
../pybitmessage-0.4.4/src/class_addressGenerator.py
../pybitmessage-0.4.4/src/helper_search.pyc
../pybitmessage-0.4.4/src/tr.py
../pybitmessage-0.4.4/src/proofofwork.py
../pybitmessage-0.4.4/src/translations/
../pybitmessage-0.4.4/src/translations/bitmessage_nl.ts
../pybitmessage-0.4.4/src/translations/bitmessage_no.ts
../pybitmessage-0.4.4/src/translations/bitmessage_zh_cn.qm
../pybitmessage-0.4.4/src/translations/bitmessage_nb.ts
../pybitmessage-0.4.4/src/translations/bitmessage_ja.ts
../pybitmessage-0.4.4/src/translations/bitmessage_eo.qm
../pybitmessage-0.4.4/src/translations/bitmessage_en.ts
../pybitmessage-0.4.4/src/translations/bitmessage_ar.ts
../pybitmessage-0.4.4/src/translations/bitmessage_sk.qm
../pybitmessage-0.4.4/src/translations/bitmessage_en.qm
../pybitmessage-0.4.4/src/translations/bitmessage.pro
../pybitmessage-0.4.4/src/translations/bitmessage_da.ts
../pybitmessage-0.4.4/src/translations/bitmessage_pl.ts
../pybitmessage-0.4.4/src/translations/bitmessage_zh_cn.ts
../pybitmessage-0.4.4/src/translations/bitmessage_cs.qm
../pybitmessage-0.4.4/src/translations/bitmessage_it.qm
../pybitmessage-0.4.4/src/translations/bitmessage_en_pirate.ts
../pybitmessage-0.4.4/src/translations/bitmessage_nl.qm
../pybitmessage-0.4.4/src/translations/bitmessage_fr.qm
../pybitmessage-0.4.4/src/translations/bitmessage_pt.ts
../pybitmessage-0.4.4/src/translations/bitmessage_ru.ts
../pybitmessage-0.4.4/src/translations/bitmessage_da.qm
../pybitmessage-0.4.4/src/translations/bitmessage_ar.qm
../pybitmessage-0.4.4/src/translations/bitmessage_no.qm
../pybitmessage-0.4.4/src/translations/bitmessage_sv.ts
../pybitmessage-0.4.4/src/translations/bitmessage_cs.ts
../pybitmessage-0.4.4/src/translations/bitmessage_ja.qm
../pybitmessage-0.4.4/src/translations/bitmessage_ru.qm
../pybitmessage-0.4.4/src/translations/bitmessage_it.ts
../pybitmessage-0.4.4/src/translations/bitmessage_sk.ts
../pybitmessage-0.4.4/src/translations/bitmessage_fr.ts
../pybitmessage-0.4.4/src/translations/bitmessage_de.qm
../pybitmessage-0.4.4/src/translations/bitmessage_en_pirate.qm
../pybitmessage-0.4.4/src/translations/bitmessage_eo.ts
../pybitmessage-0.4.4/src/translations/bitmessage_de.ts
../pybitmessage-0.4.4/src/l10n.py
../pybitmessage-0.4.4/src/class_singleWorker.pyc
../pybitmessage-0.4.4/src/class_singleListener.py
../pybitmessage-0.4.4/src/helper_search.py
../pybitmessage-0.4.4/src/pyelliptic/
../pybitmessage-0.4.4/src/pyelliptic/arithmetic.py
../pybitmessage-0.4.4/src/pyelliptic/LICENSE
../pybitmessage-0.4.4/src/pyelliptic/openssl.pyc
../pybitmessage-0.4.4/src/pyelliptic/ecc.py
../pybitmessage-0.4.4/src/pyelliptic/__init__.pyc
../pybitmessage-0.4.4/src/pyelliptic/__init__.py
../pybitmessage-0.4.4/src/pyelliptic/hash.pyc
../pybitmessage-0.4.4/src/pyelliptic/cipher.pyc
../pybitmessage-0.4.4/src/pyelliptic/arithmetic.pyc
../pybitmessage-0.4.4/src/pyelliptic/cipher.py
../pybitmessage-0.4.4/src/pyelliptic/ecc.pyc
../pybitmessage-0.4.4/src/pyelliptic/openssl.py
../pybitmessage-0.4.4/src/pyelliptic/README.md
../pybitmessage-0.4.4/src/pyelliptic/hash.py
../pybitmessage-0.4.4/src/helper_sent.py
../pybitmessage-0.4.4/src/addresses.py
../pybitmessage-0.4.4/src/helper_sent.pyc
../pybitmessage-0.4.4/src/class_objectHashHolder.pyc
../pybitmessage-0.4.4/src/api.py
../pybitmessage-0.4.4/src/api_client.py
../pybitmessage-0.4.4/src/bitmsghash/
../pybitmessage-0.4.4/src/bitmsghash/bitmsghash.cpp
../pybitmessage-0.4.4/src/bitmsghash/bitmsghash.cl
../pybitmessage-0.4.4/src/bitmsghash/Makefile
../pybitmessage-0.4.4/src/helper_sql.py
../pybitmessage-0.4.4/src/qidenticon.py
../pybitmessage-0.4.4/src/images/
../pybitmessage-0.4.4/src/images/sent.png
../pybitmessage-0.4.4/src/images/can-icon-24px-yellow.png
../pybitmessage-0.4.4/src/images/can-icon-24px.png
../pybitmessage-0.4.4/src/images/bitmessage.icns
../pybitmessage-0.4.4/src/images/redicon.png
../pybitmessage-0.4.4/src/images/can-icon-16px.png
../pybitmessage-0.4.4/src/images/blacklist.png
../pybitmessage-0.4.4/src/images/inbox.png
../pybitmessage-0.4.4/src/images/send.png
../pybitmessage-0.4.4/src/images/addressbook.png
../pybitmessage-0.4.4/src/images/qidenticon_two_x.png
../pybitmessage-0.4.4/src/images/greenicon.png
../pybitmessage-0.4.4/src/images/identities.png
../pybitmessage-0.4.4/src/images/qidenticon.png
../pybitmessage-0.4.4/src/images/subscriptions.png
../pybitmessage-0.4.4/src/images/can-icon.ico
../pybitmessage-0.4.4/src/images/qidenticon_x.png
../pybitmessage-0.4.4/src/images/qidenticon_two.png
../pybitmessage-0.4.4/src/images/networkstatus.png
../pybitmessage-0.4.4/src/images/yellowicon.png
../pybitmessage-0.4.4/src/images/can-icon-24px-green.png
../pybitmessage-0.4.4/src/images/no_identicons.png
../pybitmessage-0.4.4/src/images/can-icon-24px-red.png
../pybitmessage-0.4.4/src/debug.py
../pybitmessage-0.4.4/src/message_data_reader.py
../pybitmessage-0.4.4/src/class_sendDataThread.py
../pybitmessage-0.4.4/src/highlevelcrypto.pyc
../pybitmessage-0.4.4/src/helper_bitcoin.py
../pybitmessage-0.4.4/src/bitmessagecli.py
../pybitmessage-0.4.4/src/openclpow.py
../pybitmessage-0.4.4/src/openclpow.pyc
../pybitmessage-0.4.4/src/depends.pyc
../pybitmessage-0.4.4/src/helper_bootstrap.pyc
../pybitmessage-0.4.4/src/bitmessagecurses/
../pybitmessage-0.4.4/src/bitmessagecurses/__init__.py
../pybitmessage-0.4.4/src/helper_startup.py
../pybitmessage-0.4.4/src/helper_generic.py
../pybitmessage-0.4.4/src/class_objectProcessorQueue.py
../pybitmessage-0.4.4/src/proofofwork.pyc
../pybitmessage-0.4.4/src/class_sqlThread.py
../pybitmessage-0.4.4/src/helper_sql.pyc
../pybitmessage-0.4.4/src/class_sendDataThread.pyc
../pybitmessage-0.4.4/src/class_objectProcessor.py
../pybitmessage-0.4.4/src/helper_bootstrap.py
../pybitmessage-0.4.4/src/helper_generic.pyc
../pybitmessage-0.4.4/src/class_outgoingSynSender.py
../pybitmessage-0.4.4/ebuild.sh
../pybitmessage-0.4.4/debian/
../pybitmessage-0.4.4/debian/pybm
../pybitmessage-0.4.4/debian/changelog
../pybitmessage-0.4.4/debian/copyright
../pybitmessage-0.4.4/debian/compat
../pybitmessage-0.4.4/debian/manpages
../pybitmessage-0.4.4/debian/docs
../pybitmessage-0.4.4/debian/source/
../pybitmessage-0.4.4/debian/source/format
../pybitmessage-0.4.4/debian/source/include-binaries
../pybitmessage-0.4.4/debian/control
../pybitmessage-0.4.4/debian/rules
../pybitmessage-0.4.4/desktop/
../pybitmessage-0.4.4/desktop/pybitmessage.desktop
../pybitmessage-0.4.4/desktop/icon14.xpm
../pybitmessage-0.4.4/desktop/can-icon.svg
../pybitmessage-0.4.4/desktop/icon24.png
../pybitmessage-0.4.4/pyinstaller/
../pybitmessage-0.4.4/pyinstaller/bitmessagemain.spec
../pybitmessage-0.4.4/man/
../pybitmessage-0.4.4/man/pybitmessage.1.gz
../pybitmessage-0.4.4/puppypackage/
../pybitmessage-0.4.4/puppypackage/pybitmessage-0.4.4.pet.specs
../pybitmessage-0.4.4/puppypackage/icon14.xpm
../pybitmessage-0.4.4/puppypackage/pybitmessage-0.3.5.pet.specs
../pybitmessage-0.4.4/archpackage/
../pybitmessage-0.4.4/archpackage/PKGBUILD
../pybitmessage-0.4.4/COPYING
../pybitmessage-0.4.4/slack.sh
../pybitmessage-0.4.4/debian.sh
../pybitmessage-0.4.4/slackpackage/
../pybitmessage-0.4.4/slackpackage/slack-desc
../pybitmessage-0.4.4/slackpackage/doinst.sh
../pybitmessage-0.4.4/rpmpackage/
../pybitmessage-0.4.4/rpmpackage/pybitmessage.spec
../pybitmessage-0.4.4/rpmpackage/pybitmessage/
../pybitmessage-0.4.4/osx.sh
../pybitmessage-0.4.4/README.md
../pybitmessage-0.4.4/rpm.sh
../pybitmessage-0.4.4/configure
../pybitmessage-0.4.4/Makefile
../pybitmessage-0.4.4/puppy.sh
../pybitmessage-0.4.4/ebuildpackage/
../pybitmessage-0.4.4/ebuildpackage/pybitmessage-0.4.4-1.ebuild
../pybitmessage-0.4.4/buildroot/
../pybitmessage-0.4.4/buildroot/package/
../pybitmessage-0.4.4/buildroot/package/pybitmessage/
../pybitmessage-0.4.4/buildroot/package/pybitmessage/Config.in
../pybitmessage-0.4.4/buildroot/package/pybitmessage/pybitmessage.mk
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.6xc2LV
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd /root/rpmbuild/BUILD
+ rm -rf pybitmessage-0.4.4
+ /usr/bin/gzip -dc /root/rpmbuild/SOURCES/pybitmessage_0.4.4.orig.tar.gz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd pybitmessage-0.4.4
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.nCDRWE
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd pybitmessage-0.4.4
+ CFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic'
+ export CFLAGS
+ CXXFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic'
+ export CXXFLAGS
+ FFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -I/usr/lib64/gfortran/modules'
+ export FFLAGS
+ FCFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -I/usr/lib64/gfortran/modules'
+ export FCFLAGS
+ LDFLAGS='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
+ export LDFLAGS
+ '[' 1 = 1 ']'
+++ dirname ./configure
++ find . -name config.guess -o -name config.sub
+ '[' 1 = 1 ']'
+ '[' x '!=' x-specs=/usr/lib/rpm/redhat/redhat-hardened-ld ']'
++ find . -name ltmain.sh
+ ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info
+ make -j4
make: Nothing to be done for 'all'.
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.XWcZ3o
+ umask 022
+ cd /root/rpmbuild/BUILD
+ '[' /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64 '!=' / ']'
+ rm -rf /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64
++ dirname /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64
+ mkdir -p /root/rpmbuild/BUILDROOT
+ mkdir /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64
+ cd pybitmessage-0.4.4
+ rm -rf /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/etc
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/etc/pybitmessage
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/bin
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/man
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/man/man1
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/pybitmessage
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/applications
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons/hicolor
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons/hicolor/24x24
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons/hicolor/24x24/apps
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/pixmaps
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons/hicolor/scalable
+ mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons/hicolor/scalable/apps
+ make install -B DESTDIR=/root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64 PREFIX=/usr
mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr
mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr
mkdir -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/bin
mkdir -m 755 -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share
mkdir -m 755 -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/man
mkdir -m 755 -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/man/man1
install -m 644 man/pybitmessage.1.gz /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/man/man1
mkdir -m 755 -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/pybitmessage
mkdir -m 755 -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/applications
mkdir -m 755 -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/pixmaps
mkdir -m 755 -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons
mkdir -m 755 -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons/hicolor
mkdir -m 755 -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons/hicolor/scalable
mkdir -m 755 -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons/hicolor/scalable/apps
mkdir -m 755 -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons/hicolor/24x24
mkdir -m 755 -p /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons/hicolor/24x24/apps
install -m 644 desktop/pybitmessage.desktop /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/applications/pybitmessage.desktop
install -m 644 desktop/icon24.png /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/icons/hicolor/24x24/apps/pybitmessage.png
cp -rf src/* /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/pybitmessage
echo '#!/bin/sh' > /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/bin/pybitmessage
echo 'if [ -d /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/pybitmessage ]; then' >> /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/bin/pybitmessage
echo '  cd /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/pybitmessage' >> /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/bin/pybitmessage
echo 'else' >> /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/bin/pybitmessage
echo '  cd /usr/share/pybitmessage' >> /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/bin/pybitmessage
echo 'fi' >> /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/bin/pybitmessage
echo 'LD_LIBRARY_PATH="/opt/openssl-compat-bitcoin/lib/" exec python2 bitmessagemain.py' >> /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/bin/pybitmessage
chmod +x /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/bin/pybitmessage
+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 /root/rpmbuild/BUILD/pybitmessage-0.4.4
/usr/lib/rpm/sepdebugcrcfix: Updated 0 CRC32s, 0 CRC32s did match.
+ '[' noarch = noarch ']'
+ case "${QA_CHECK_RPATHS:-}" in
+ /usr/lib/rpm/check-buildroot
/root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/bin/pybitmessage:if [ -d /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/pybitmessage ]; then
/root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/bin/pybitmessage:  cd /root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64/usr/share/pybitmessage
Found '/root/rpmbuild/BUILDROOT/pybitmessage-0.4.4-1.fc23.x86_64' in installed files; aborting
error: Bad exit status from /var/tmp/rpm-tmp.XWcZ3o (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.XWcZ3o (%install)
```

user: Truckle
labels: bug: Something isn't working as it's supposed to
issue_859: state: open
title: Grammar: "need-not" -> "need not"
body: If you search for "need-not" in google books, you will see that it is overwhelmingly used without the hyphen: "need not". "need-not" is (possibly) a rare noun, and is also (possibly) a UK spelling of "need not" as a verb.

user: yurivict
labels: bug: Something isn't working as it's supposed to
issue_856: state: open
title: Not all new messages are shown on the subscriptions tab
body: 'Subscriptions' tab shows that there are new messages (in bold), but not all new messages are displayed there. 'Messages' tab though shows all new messages from the subscription channels.

user: yurivict
labels: bug: Something isn't working as it's supposed to
issue_855: state: open
title: 100% cpu utilization on Mac OS X
body: Bitmessage v0.6.0 works OK, but uses 100% CPU after identity generation (8 identities, passphrase). If reopen the application it works OK.

macb:~ sergey$ ps aux | grep Bi
sergey            589 **397.2**  4.1  3116788 173496   ??  R     9:41PM  12:16.14 /Volumes/Bitmessage/Bitmessage.app/Contents/MacOS/Bitmessage -psn_0_127007

macb:~ sergey$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.9.5
BuildVersion:   13F1507

user: svlobanov
labels: enhancement: New feature
issue_848: state: open
title: New API calls
body: Came over BM:

No, the API's clientStatus doesn't give that info. But it gives some other useful info so I can implement at least that, thanks for the suggestion (wait for apiclient.py v1.25).

What angers me more about the API is that it doesn't allow to list only the headers of messages, i.e. everything except the message body, like what you get with apiclient.py -l or --ls. Each time I have to grab the whole inbox or the whole sentbox and then show you just headers. If you had hundreds of messages, let alone with the binary files, that would mean MBs if not GBs of useless data transfers :-(

I can easily add the knownnodes info into the clientStatus, add getAllInboxMessagesHeaders and getAllSentMessagesHeaders and fix the broken listAddresses2, but then it will only be in my API and not yours. I can't make a pull request on github because I communicate only via BM. I wish there was a chan where developers could just post their patches and if they were simple and straightforward they would get prompty merged into the github tree..

user: PeterSurda
labels: enhancement: New feature
issue_846: state: open
title: Spell checking
body: A user suggested over BM that spellchecking would be a good feature. We obviously can't use online checking API so somehow the languages would have to be bundled, or there could be an option to download it separately.

user: PeterSurda
labels: enhancement: New feature
issue_841: state: open
title: User interface for bitcoin payments
body: Gmail has its own version of send money between users, we can also have our own. It does not necessarily mean integrating a bitcoin wallet, just qr code generation and integration.

user: PeterSurda
labels: enhancement: New feature
issue_839: state: open
title: Conversation view
body: Some email clients, allow to view message exchanges as conversations. Example would be gmail website or android app. Some email clients, for example aquamail for android, allow to switch between the two. Bitmessage should also allow this. However, it may require a new message type which contains references to previous messages, like Message-ID, References, In-Reply-To email headers.

Example of threading code by including explanation here: https://www.jwz.org/doc/threading.html

Requires #840 

user: PeterSurda
labels: enhancement: New feature
issue_834: state: open
title: SOCKS flood
body: Apparently, SOCKS (e.g. Tor) can get overloaded by syn flood. I haven't experienced this but people reported it in the general chan. One suggested solution is to reduce maximumNumberOfHalfOpenConnections when using Tor. Another one is to increase  MaxClientCircuitsPending in torrc.

Apparently, this can happen on Tails, the suggestion is "either remove IsolateDestAddr and IsolateDestPort or increase the MaxClientCircuitsPending but consult the manual first."

Maybe PyBitmessage can try to detect Tor config and adjust accordingly. Apparently Tor has a RPC so maybe this can be used for this purpose.

Having a large number of half-open connections is considered abuse of Tor.

user: PeterSurda
labels: bug: Something isn't working as it's supposed to
issue_833: state: open
title: PFS
body: A new address version that contains expiring ephemeral subkeys (which are not a part of the address itself) would allow something like PFS. It requires some design, to make sure they keys are not deleted prematurely for example.

For a proposal, see here: https://www.reddit.com/r/bitmessage/comments/3zzevp/forward_secrecy_for_bitmessage/

user: PeterSurda
labels: enhancement: New feature
issue_832: state: open
title: Encryption of database
body: https://pypi.python.org/pypi/pysqlcipher/

user: PeterSurda
labels: enhancement: New feature
issue_831: state: open
title: Encryption of config file
body: https://pypi.python.org/pypi/secureconfig/

user: PeterSurda
labels: enhancement: New feature
issue_828: state: open
title: [Suggestion] Bitmessage as a plugin for Thunderbird
body: This is just a suggestion, you may close it if you are not interested.

We have all seen in the past few weeks how Signal (Android/iOS encrypted messaging app) has grown in popularity (between 1 and 5 million downloads on Android at the time of this writing). I think the fact that it still allows, within the same app, to access and use the "old feature" (in this case, texts) played a big role in its success.
Not everyone is using Signal, and having the possibility to still send messages to users who don't, without having to change app is the key.

Bitmessage is a great idea, but it lacks this possibility to send messages to people who haven't (yet) switched to it.
My first thought was obviously some kind of integration with Thunderbird. People would still use a software they are familiar with, but they could also send encrypted messages to others who can receive them.

I don't know enough about Thunderbird inner workings to say if it is even possible with a plugin, but I think it would be a big step in making Bitmessage more popular, and allow people to use it without the inconvenience of having to maintain 2 separate programs. We all know how it goes, when something requires extra work, and it is not absolutely necessary, people just give it up.

This is just my 2 cents on the matter. I think Signal did it right, and it obviously paid off. :dart: 

user: fabienb4
labels: enhancement: New feature
issue_823: state: open
title: distributed moderator
body: I heard that for public channels there is thoughts to centralize the moderators for each channels. This is a problem in that it increases your legal liability.

There are other methods to consider instead:
1. Perhaps what if you can subscribe to a group or individual, to which you can listen to their recommendation of post to not display or forward (or both) within bitmessage. (e.g. they send bitmessages of recommendation to approve or revoke or block senders or messages).
2. Interface could be based on a 3 star rating. You or others that you subscribed to as moderator can vote up or down up to 3 to -3 points. If a user subscribes to multiple moderating teams, these score are aggregated together, with user defined weighting.
3. Every post should have an optional field to carry a recommendation for a moderator or moderating group's broadcast channel, so that if you find a poster that you can trust... you can instantly subscribe to them to listen to their moderating advice (or a group they recommend).
4. Oh and instead of simple allow/block judgement, perhaps moderator groups could do other things like: Increase proof of work requirements to forward, view, etc.. 

---

As you can notice, this does not require any centralized moderator. This is more of a federated approach.

user: mofosyne
labels: enhancement: New feature
issue_818: state: open
title: translation of software
body: what's the goal / status / general motivation about translation the interface options, help, documentation etc?
Is it being done, or is there work necessary to do, where one could translate with the help of other people?

user: ghost
labels: enhancement: New feature
build: Related to building or build system
regression: Some issue, fixed in the past, appears again
issue_813: state: open
title: Message signatures per identity
body: Would it be possible to add message signatures for each identity? E.g., when I start a new message and pick an identity, it would autofill the signature at the bottom:

```
Message message, message message

---
Signature
```

So you could remove it if you wanted for each individual message.
I'd be happy to implement this if someone could clarify to me how identities are stored.

user: NoraCodes
labels: enhancement: New feature
issue_808: state: open
title: Mobile message & behavior bitfield support
body: This patch implements the behavior bitfields described at https://bitmessage.org/wiki/Protocol_specification#Pubkey_bitfield_features .

A checkbox is added to address creation allowing the creation of mobile addresses.
When sending to mobile addresses, toRipe.lstrip('\x00') is prefixed to the encrypted message.

Two config options are added per address: needripe, indicating a mobile address, and notsendack, indicating an address that will not send acknowledgements.  Code is implemented to honor these options.

user: kyucrane
labels: enhancement: New feature
issue_785: state: open
title: PyBitmessage has no official PPA
body: Both PPAs I have examined are very out of date. This would greatly help usability for all Ubuntu-descended (and probably Debian-descended) users.
#135, #746

user: deutrino
labels: enhancement: New feature
issue_777: state: open
title: get Network Status from API
body: all informations from the "Network Status" Tab

i want to deploy a headless node with a webinterface to show the processed messages/public keys, transferred data and inventory lookups with a nice realtime graph.

user: davidak
labels: enhancement: New feature
issue_772: state: open
title: Additional services
body: Hi.

I'd like to introduce several new node types compatible with the Bitmessage protocol: `NODE_MOBILE` and `NODE_GATEWAY`. They are almost identical to the nodes described here: https://bitmessage.org/wiki/Mobile_Protocol_specification

But several `PyBitmessage` quirks stop me:
- `PyBitmessage` doesn't check `services` bitfield at all. This means that if I advertise node which uses non-TCP transport with `services = 4` (BE value), `PyBitmessage` will constantly try to connect to it despite the fact the node hasn't `NODE_NETWORK` bit.
- ~~I can't advertise `NODE_NETWORK` and `NODE_GATEWAY` node as two different `addr` entries with the same IP because `knownNodes` structure is a host-ip/host-details map.~~ Oops, I missed the fact `knownNodes` is a host+port/host-details map now.
- Even if I advertise `NODE_GATEWAY` as a separate `addr` entry, PyBitmessage won't be able to connect to it anyway so `NODE_GATEWAY` addresses will propogate badly through the network because of the node alive checkings: https://github.com/Bitmessage/PyBitmessage/blob/master/src/class_receiveDataThread.py#L666
- `PyBitmessage` currently doesn't  take into account `services` field when it packs the `addr` message: https://github.com/Bitmessage/PyBitmessage/blob/master/src/class_receiveDataThread.py#L672, https://github.com/Bitmessage/PyBitmessage/blob/master/src/class_receiveDataThread.py#L275

So far I know one rather awkward solution: advertise `NODE_NETWORK` and `NODE_GATEWAY` fields (i.e. `services = 5`) as single `addr` entry and use hardcoded port for non-TCP transports (e.g. 18444) but this is rather tricky.

user: Kagami
labels: enhancement: New feature
issue_769: state: open
title: Bit numbering scheme in pubkey/service features
body: Hi. Another spec quirk.

Service features bitfield uses LSB 0:
https://github.com/Bitmessage/PyBitmessage/blob/master/src/shared.py#L149
https://bitmessage.org/wiki/Protocol_specification#version

At the same time pubkey behavior bitfield uses MSB 0:
https://github.com/Bitmessage/PyBitmessage/blob/master/src/class_singleWorker.py#L272
https://bitmessage.org/wiki/Protocol_specification#Pubkey_bitfield_features
https://github.com/Bitmessage/PyBitmessage/blob/master/src/class_singleWorker.py#L747
https://github.com/Bitmessage/PyBitmessage/blob/master/src/shared.py#L469

Should we be more consistent or at least mention this contradiction in the wiki?

user: Kagami
labels: enhancement: New feature
issue_745: state: open
title: Feature request: way to get sync progress from API
body: It would be nice if there were a way to get some rough measure of sync progress via the API. Something like: 1) the number of total cached messages visible on connected nodes and 2) number of cached messages on local node. This way clients could poll it to display sync progress to the user. Otherwise, they think it's broken and see no reason to leave the app open while it syncs.

user: stevedekorte
labels: enhancement: New feature
issue_739: state: open
title: Separate BM core and GUI client
body: Are there any plans or intention to separate the PyMessage GUI from the core bitmessage node? Tox does this nicely by maintaining [tox-core](https://github.com/irungentoo/toxcore) separately from its myriad of clients. Given that the community has already demonstrated an interest[[1](https://github.com/chovy/bmr)][[2](https://github.com/jclement/bitmessage-web)][[3](https://github.com/noffle/bitomail)] in alternative clients, it would be nice to see the BM core stand on its own. Other pluses include a lighter-weight (and lower dependency) core due to the GUI features not being present, and a bug tracker that provided clean partitioning of BM core issues vs UI issues.

user: hackergrrl
issue_695: state: open
title: Message count limit
body: Please add the limit to a maximum number of inbox messages. There are too many of them and removing very very very old ones is slow if doing it manually.

user: neko259
labels: enhancement: New feature
issue_690: state: open
title: Plausible deniability with Bitmessage
body: My first post here, I'm sorry if I do something not according to the rules here.

I have a problem with plausible deniability regarding Bitmessage.

I see all keys etc are stored in the same way as Bitcoin does. This is good and bad for plausible deniability.
Both BItcoin and Bitmessage use broadcasting messages over the network to 'spread the word'. I think I have figured out a way to positively identify what IP-address belongs to what transaction in Bitcoin, and suppose I could apply the same techniques to identify what IP belongs to what sender in Bitmessage. If I can do this, anyone can. (currently testing the application in a lab, will report later)

The issue I have is that it is possible for people to learn that the IP of my home computer is connected to my public key. If I understand Bitmessage correctly, everyone can see to what public key a message is addressed, but only the holder(s) of the corresponding private key can read the message. 
# 

scenario:
One could therefore find out that I, Robbie, am messaging with a known evil person using Bitmessage, let's name him Jim. Even though I message Jim a lot, I also message my contacts Paul and Emma a lot.

Something happens, Jim is involved, and they go through his contacts. Assuming Issue #267 is implemented, they would not be able to see what messages Jim received. They would be able to see that I messaged Jim a lot.

Next stop, they knock on my door.

As I only have one pool of keys, when I want to show that "I have never been involved with Jim" unlocking my client is not going to be an option
# 

What I would like is the option to load specific keys using the (G)UI of the application.

(I'm not going to change my keys.dat file in /user/library/application support/PyBitmessage/ every time I want to message another contact. The UI can do this for me tho.)

I would like a simple option to open a keypair on any storage device connected to my computer. I can use one key per contact or contactset and simply load in the keypair from my encrypted storage whenever I want to check for messages.

This way, when I get raided over something one of my contacts did, I can claim someone must have broken into my wifi and abused it, as I do not have access to the keys they are looking for.

user: F1k
labels: enhancement: New feature
issue_678: state: open
title: API new commands
body: Hello,

It would be wonderful to get the following commands in the API:
## getAddress

args: `<address>`
Returns: address, label
Targets: either addressbook or personnal addresses
## updateAddressLabel

args: `<address>` `<label>`
Returns: success if address exists and has been updated, failuer otherwise
Targets: either addressbook or personnal addresses

Use cases:
the first one will allow to get the label related to an address — may be good for some application devel.

The second one aims to allow label update — this would let us use the createDeterministicAddress and set up later a proper label, different from the default one

I _may_ have a look in order to properly implement that… But I don't promise it

Cheers,

C.

user: cjeanneret
labels: enhancement: New feature
issue_659: state: open
title: Support of/bridge to GnuPG
body: I would like to sign/encrypt Bitmessage with GnuPG as well.

In order to do this in a user friendly way, PyBitmessage could offer functionality to quickly sign, encrypt, sign+encrypt, check signatures, and decrypt message body accordingly.

user: novoid
issue_632: state: open
title: Receive "old" messages after joining a chan
body: After joining a chan, try to decrypt all messages currently stored (from the two-day window) with its private keys and (optionally?) display them in the inbox.  See https://bitmessage.org/forum/index.php?topic=3702.0.

user: domob1812
labels: enhancement: New feature
issue_565: state: open
title: Encrypt .dat files 
body: Hi add keys.dat  encryption for Bitmessage .
PyElliptic is a high level wrapper for the cryptographic library 
https://github.com/yann2192/pyelliptic
The Python Cryptography Toolkit
https://github.com/dlitz/pycrypto
 Implementation of keys.dat encryption in AES-256-CBC using pyelliptic
https://bitmessage.org/forum/index.php/topic,2689.0.html
[QuickFix] encrypted messages.dat keys.dat and knownnodes.dat
https://bitmessage.org/forum/index.php/topic,1589.15.html

user: drkiko
issue_563: state: open
title: Forward anonymity
body: Forward anonymity, analogous to forward secrecy, in computer security and cryptography is the property which prevents an attacker who has recorded past communications from discovering the identities of the participants, even after the fact.

When speaking of forward secrecy, system designers attempt to prevent an attacker who has recorded past communications from discovering the contents of said communications later on. One example of a system which satisfies the perfect forward secrecy property is one in which a compromise of one key by an attacker (and consequent decryption of messages encrypted with that key) does not undermine the security of previously used keys.

When speaking of forward anonymity, system designers attempt to prevent an attacker who has recorded past communications from discovering the identities of the participants, even after the fact. This property is not to be confused with sender (or receiver) anonymity, in which the identity of the sender (or receiver) remains unknown to all entities in the system.Add this if is posible .
Source http://en.wikipedia.org/wiki/Forward_anonymity
http://www.python.org/dev/peps/pep-0403/

user: drkiko
labels: enhancement: New feature
issue_543: state: open
title:  New Feature: Menu File Backup/Restore your data GUI 
body: Please see this forum topic 
https://bitmessage.org/forum/index.php/topic,3306.0.html

user: drkiko
labels: enhancement: New feature
issue_539: state: open
title: Use __del__ as destructor - bad!
body: Hi and sorry for my bad English.
I am not python guru, but i think what use  **del** as destructor is  bad. ( cipher.py, singleton.py) 
For some details: http://stackoverflow.com/a/1481512/363249

user: 7histle
labels: bug: Something isn't working as it's supposed to
issue_536: state: open
title: need api call to manage blacklist for addresses
body: We need an api call that will manage blacklists for addresses.
the spam is killing bitmessage.

user: ralyodio
labels: enhancement: New feature
issue_533: state: open
title: loading keys.dat takes a huge amount of time (includes possible fix)
body: I start noticing lags in the client with the nearly 4000 addresses I have registered at bitmessage.ch. This goes so far, that the client due to being only "sort of" multi-threaded not being able to do certain tasks.
What I detected so far is, that keys.dat is reloaded every once in a while without any reason. if somebody tries to register an account during this time on bitmessage.ch, the API completely locks up and no longer answers, until the file is completely reloaded. (takes about 10 minutes so far)

is there a reason, the file gets reloaded every once in a while?

What I did to fix it in shared.py was
1. Adding a new array `TMPaddrList = {}` on the top of the file
2. changed reloadMyAddressHashes() to check, if the address has already been added.

``` python
if addressInKeysFile in shared.TMPaddrList:
    print 'Address',addressInKeysFile,'already loaded' #existing, do nothing
else:
    print 'loading address',addressInKeysFile #process address
    #ADDRESS_LOADING_HERE

shared.TMPaddrList=configSections
```

You may want to add something like that to the official code. In the address creation window you tell users to use throw-away addresses to enhance their anonymity. If they do this, they certainly will slow down their client over time.

user: AyrA
labels: bug: Something isn't working as it's supposed to
issue_529: state: open
title: trash calls do not update sent table.
body: sending an API call to trash a sent message wont update the UI of bitmessage.

user: AyrA
labels: bug: Something isn't working as it's supposed to
issue_527: state: open
title: A Gentle Reminder to All Bitmessage Developers !!!
body: Dear colleagues,

In order to make the Bitmessage code scalable and flexible in terms of making changes/adding features please use non-static references to objects.
For example I found all over the code statements like this:

<b>self.ui.tabWidget.setTabText(6, 'Whitelist')</b>

Instead it should be:

<b> self.ui.tabWidget.setTabText(self.ui.tabWidget.indexOf(self.ui.blackwhitelist), 'Whitelist') </b>

Otherwise, if you add a tab somewhere in between the existing tabs it will mess up everything.

Thanks !
Arnukk

user: Arnukk
labels: enhancement: New feature
issue_470: state: open
title: Facilitate bitmessage support in Adium
body: I'm pretty new to bitmessage, but wondering whether we could discuss the theoretical possibility of creating a bitmessage plugin for adium. Anyone familiar with adium development and know whether it's possible, or what might need to happen first?

cc: @sheedy @wixardy @RobFog @xnyhps

user: patcon
labels: enhancement: New feature
issue_454: state: open
title: Perfect Forward Secrecy
body: Abstract

This document describes a method of key exchange and use to achieve Perfect Forward Secrecy. A means of encryption to ensure that, should a single message be decrypted, all other parts of the conversation remain secure.

This specification consists mainly of two parts. The first part describes the method of key exchange and generation of subsequent keys. The second part describes a usage pattern to insure no messages are lost and authenticated to come from the expected source.

Lastly, a simple method for plausible deniability is given.

This proposal does not try to solve node profiling attacks (ISP level monitoring of nodes).

Motivation

The Bitmessage protocol uses a fixed set of keys per address to encrypt and sign messages. Should one message be compromised, the other messages sent to the same address are at risk as well.

Perfect Forward Secrecy uses a new set of keys to encrypt and sign each message.
More info https://bitmessage.org/forum/index.php/topic,2981.0.html
https://github.com/sipa/secp256k1
Python library http://docs.python.org/3/library/ssl.html
Interesting article .
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html

user: drkiko
labels: enhancement: New feature
issue_430: state: open
title: Proof of work setting allows address correlation
body: # Summary

Sending a message to a recipient with a nonstandard proof-of-work requirement allows the sender to determine whether or not the originating address is part of the receiver's address book. This poses a problem because it allows address correlation.
# Reproduction steps
- Alice has a proof-of-work setting of 2.
- She maintains two addresses, A1 and A2, which she does not want correlated.
- A1 communicates with Bob frequently, so Alice adds his address, B1, to her address book.
- **Bob can now confirm that A1 and A2 are the same person** by sending each two messages, one from B1 and one from B2. B1 will be notified by both A1 and A2 that it only needs a proof-of-work difficulty of 1, while B2 will not.

---

**Suggested remedy**: Remove the custom proof of work functionality, at least from the client.
**Source:** https://bitmessage.org/forum/index.php/topic,2969.0.html

user: nimdahk
labels: bug: Something isn't working as it's supposed to
issue_407: state: open
title: OTR in comparison wiki table
body: https://bitmessage.org/wiki/FAQ#How_does_Bitmessage_compare_to_other_messaging_methods

I don't think OTR fits in there. OTR is encryption protocol, not a protocol like jabber or messenger like pidgin.

TorChat2 will include OTR. Crypocat includes OTR.

Hide sender / hide receiver depends on the underlying protocol/messenger. OTR won't mess that up.

OTR should be on the same level as Hide Sender Hide Receiver etc.
- Does bitmessage use OTR? No.
- Does Skype use OTR? No.
- Does Cryptocat use OTR? Yes.
- Does Pidgin use OTR? Available as a plugin.

user: adrelanos
labels: enhancement: New feature
issue_284: state: open
title: Keyboard shortcut issues
body: I was contacted about an issue regarding keyboard navigation in bitmessage. I could not replicate the Ctrl+Tab issue in my .exe compiled version but perhaps someone else could. 

"But regarding the keyboard behavior, try to reproduce the problem by these 
steps:

Start the client.
Press Ctrl+Tab, and you are in the
main window.

Pressing Ctrl+Tab brings up respectively Inbox, Send, Sent, Your Identities, 
Subscriptions, Addressbook, Blacklist, Network Status.

Pressing Ctrl+Tab moves to the next and Ctrl+Shift+Tab to the previous 
window.

So far so good, but  press tab once more for example  to bring up the Inbox.

Ctrl+tab does not bring up the next window (Send) while you are stuck inside 
the Inbox or any other menu.

Only the mouse does.
Regardless where you are, Ctrl+Tab and Ctrl+Shift+Tab should always bring up 
the next and previous menu.

So if you are in the Inbox pressing Ctrl+Tab should bring up Send, Your 
Identities  etc.

I would also like to have keyboard  shortcuts for bringing up Settings and 
exiting the program.

This would also be useful for people depending on the keyboard for other 
reasons - like accessibility aids."

user: Dokument
labels: enhancement: New feature
issue_283: state: open
title: Threaded Inbox
body: I suggest to add some basic support for threaded Inbox, e.g. sorting messages by grouping topics and dates.
I've never had any chance to work with Python before but I managed to make some changes to source code to display Inbox with threads. This is far from the final version but it seems to be much more usable than keeping 2 separate tabs each containing 10 topics with 5-20 messages each topic distributed across the inbox and outbox. Managing big number of messages/topics with Inbox/Outbox scheme is a real pain.

I don't know how to push my changed yet. I'm new to git.

I attach a slightly modified screenshot. I've removed some sensitive info (original titles+contacts) but it still gives a general overview of proposed changes.
![bm1](https://f.cloud.github.com/assets/4932919/745733/1382e1ba-e419-11e2-91a9-9631fdc0a1d9.png)

user: IvanCool
labels: enhancement: New feature
issue_267: state: open
title: Private encryption and signing keys should be encrypted
body: If we consider issue https://github.com/Bitmessage/PyBitmessage/issues/256 to be a prerequisite to this, we could encrypt the entire keys.dat file.

I see this working similar to the following:

Any save operations would save out encrypted using an (AES) encryption key generated from a user provided password combined with a random salt. The random salt would prefix the encrypted data. This would allow it be retrieved and used with the password for decryption.
- When PyBitmessage starts up for the first time and the keys.dat _does not_ exist, the user would be prompted for a password. After a password is entered, an encrypted keys.dat file would be created.
- When PyBitmessage starts up and the keys.dat _does_ exist, the user would be prompted for the password and the keys.dat would be decrypted in memory. This decrypted data would then fed and equivalent of the current shared.config object and be accessed as usual by the rest of the program. 

Unfortunately, due to the fact decrypted must be attempted against every message received, we have to store the private keys decrypted in memory while the program remain running. I can't think of any way around this without the inconvenience of the user being prompted for the password every time a new message comes in.

I'd really like to hear everyone's thoughts, feedback and ideas. This is a reasonably big/complex change so it really needs to be got right.

user: DivineOmega
labels: enhancement: New feature
issue_258: state: open
title: insecure keys.dat permissions
body: Currently, keys.dat is created with default permissions on Linux, which often have insecure 644 permissions that are unsatisfactory for keyfiles. I don't know about OSX nor Windows, but I assume they have the same issue. The keys.dat file should be created with a 077 umask.

user: fiatflux
labels: enhancement: New feature
issue_256: state: open
title: Keys.dat should only contain private keys
body: The existing keys.dat also contain application settings/preferences.

I suggest the following:
- keys.dat - only contains primary keys
- settings.dat - contains all settings/preferences for the application

This will allow users to backup the most important data, their private keys, independent of the application settings.

user: DivineOmega
issue_250: state: open
title: Separate user data and network data into two SQLite databases
body: The messages.dat SQLite database contains a lot of information, but most of it, in terms of storage during general use, is network data (the encrypted messages and public keys).

I believe we should separate user data from network data. This would allow users to back up their inbox, sent items and address book separately from the network data. It could also potentially improve performance in the future, by allowing the user and network data to be managed by two separate threads.

My thoughts are as follows:

_messages.dat_ contains the following tables:
- inbox
- sent
- subscriptions
- addressbook
- blacklist
- whitelist
- settings

_network.dat_ contains the following tables:
- inventory
- pubkeys
- knownnodes
- settings

The settings table needs to be included in both to allow independant database version numbers and last vacuum timestamps.

I'm not certain about the 'pubkeys' table, due to 'usedpersonally' field.

I quite like the idea of two separate SQL threads being used, one per database.

What are people's thoughts?

user: DivineOmega
issue_206: state: open
title: Wiki translation
body: To reach more people, should it be possible to translate the wiki pages?

Here is a module for Mediawiki: https://www.mediawiki.org/wiki/Help:Extension:Translate/Page_translation_example

And the installation procedure: https://www.mediawiki.org/wiki/Help:Extension:Translate/Installation

user: Astalaseven
labels: enhancement: New feature
issue_194: state: open
title: [Request] Change/Add API commands
body: # Change API commands

generally commands should be changed, so the "addSomething" commands will actually edit existing entries.
# More API Commands

Below you can find suggestions
## exit

If your client runs in daemon mode on windows you currently have to kill the process which may lead to a corrupt messages.dat file. Calling the exit command would gracefully shut down the client
## showGui

Causes the GUI to be loaded and shown to the user.
## emptyTrash

Does the same as the command in the File menu.
## updateGUI

Allows a user to update the GUI.
## getSubscriptions

Returns a list of subscriptions (address, Label, enabled)
## getAllInboxID

The same as getAllInboxMessages but only returns ID's, causing a more performannt API because people do not always need all their 8000 Messages at once
## getMessage

Gets the message with specified Message ID
## addAddressbookEntry

Adds/edits an address book entry
## getAddressbookEntries

Returns a list of address book entries
## deleteAddressbookEntry

Deletes an address book entry.
## addBlacklist

Adds a message to the Blacklist
## deleteBlacklist

Removes a Message from the blacklist
## getBlacklist

Returns all Items in the blacklist
## add|get|delete Whitelist

Same as Blacklist but for the Whitelist.
## setListMode

sets BM to blacklist or whitelist mode
## getListMode

gets the current blacklist/whitelist mode.
## getNetStatus

returns a list of connected nodes (IP/Port) and the number of processed messages and public keys.
## connect

Connects to specified IP and Port (only makes sense if automatic connection attempts from bitmessage can be disabled)
## disconnect

Disconnects from an IP
# Additional commands

Additional commands should be added if an IP based black/whitelist is ever created, supporting adding/removing/returning IP addresses or ranges.

user: AyrA
labels: enhancement: New feature
issue_190: state: open
title: [Enhancement] CPU load optimization
body: ## Issue

Currently a message is tried to be decrypted by the client, causing it to create high CPU load for long messages, even if they are undecryptable.
## Expected Behavior

Only decrypt a message completely when required.
## Implementation

To accomplish this, include a checksum of the first 16 encrypted bytes (or whatever the block size is) at the beginning of the encrypted Message. The checksum itself must be in the encrypted message to prevent it from being modified.
## Result

The client will only decrypt big messages if the initial chunk was decrypted successfully, preventing high CPU load with increasing number of messages or large Messages in the network.

user: AyrA
labels: enhancement: New feature
issue_168: state: open
title: [Enhancement] show sent and incomming messages in a conversation
body: If you send and receive a lot of messages with the same person, it is hard to follow the thread.

It would help, if you would save the connection between a message in your inbox and the sent answer.

Or even better: show messages in a conversation like in Thunderbird (invented by gmail)

user: rubo77
labels: enhancement: New feature
issue_165: state: open
title: non-ascii character in the path of messages.dat
body: Hello,
when you are determining the appdata path on windows, you get the value in whatever encoding windows chooses, which then results in an OperationalError during db connection opening. It would be useful to decode it to an unicode string, perhaps using sys.getfilesystemencoding. And it would help to have the whole logic only in shared, not duplicated it in the main script. Or is there any difference?

user: tyrylu
labels: bug: Something isn't working as it's supposed to
issue_164: state: open
title: Minor nice features
body: This is just my list of things that I feel like should be put into bitmessage asap. I understand that bug fixes and other issues may have to come first. 
- [ ] Known Nodes - The ability for the user to specify their own nodes (replacing the default known nodes when used).This is the only centralized thing in bitmessage and once it is gone, it can be advertised as fully decentralized.
- [ ] LAN/WAN - An option to switch between lan or wan operation. It should be an "or" option and not an "and" option. This also requires users to input their own known node when in LAN use.
- [ ] Flag/Star/Unread - Some way to mark messages for future reference. I would think that marking a message unread or the ability to flag/star it would be the easiest way to do this.

user: Dokument
labels: enhancement: New feature
issue_105: state: open
title: Feature Request: Message Encoding 'FILE'
body: It would be really cool if there were a message encoding type to transfer files, in simple binary format.

user: ISibboI
labels: enhancement: New feature