<commit_before>BitPool
=======

Combination shared mailbox + mix network + remailer service with wider connectivity over BitMessage P2P network<commit_msg>Updated README with some details.<commit_after>BitPool
=======

Combination shared mailbox + mix network + remailer service with wider connectivity over BitMessage P2P network

Rationale
---------

BitMessage requires clients to prospectively attempt to decrypt all messages, making it rather unsuitable for mobile clients, which - annoyingly - is one of the if not the most important potential applications for it.

When people communicate it it often in smaller groups than that of the entire world, so allowing some congregation into the smaller networks the vast majority of us inhabit - and so with it shrink computational and bandwidth requirements with it - seems a natural choice. At the same time, it would be nice to not give up too much anonymity.

BitPool is designed to do just that, through allowing users to join whatever pool(s) they like. If one is primarily concerned with optimising for the use case of talking primary to their circle of contacts, then one can set up a pool for that. Otherwise, or and, they may join a random pool, and so gain some additional anonymity.

The pool should allow them to send messages to other members of the pool 1) without performing any Proof of Work (PoW), *or* 2) some small amount (up to configuration of the pool), reflecting that no (quite extensive in mobile terms) BitMessage PoW was required to be performed. 
In the event that the person with which they wish to speak is not located in that pool, the message should be routed out of the pool and into the wider BitMessage network, arriving at either a standard BitMessage address, or at another pool.

A user should receive their messages from a pool just like how BitMessage itself works (prospective decryption), but in a much smaller scale. The connection between the user and the pool should be encrypted (although not strictly necessary even), but most probably not with SSL. Most probably the encryption will be derived from a token the user receives when first setting up with the pool (symmetric cipher), or some asymmetric scheme (like 1-Pass Unified Model EC-DHC).

** *Note:* These details are still being worked out currently, but that is the forecast. If you have any suggestions for improvements or corrections, please do.**

{'fraction_non_alphanumeric': 0.041130037390943085, 'fraction_numerical': 0.002077274615704196, 'mean_word_length': 4.613053613053613, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6899997', 'n_tokens_mistral': 544, 'n_tokens_neox': 518, 'n_words': 377}