Some considerations:

* libbitcoin is a source of types, constants, conversion and utility
functions and classes.
* each repo has a primary namespace which maps to the header name.
* libbitcoin is a dependency of all of the other libs.
* libbitcoin's namespace is the base for all others.
* libbitcoin's repo name appears like a base for all others.

From the roadmap (with some updates):
https://wiki.unsystem.net/en/index.php/Libbitcoin#Roadmap

libbitcoin            bc::           Core + utility
libbitcoin_wallet     bc::wallet::   (folded into libbitcoin)
libbitcoin_network    bc::network::  Network (Satoshi protocol)
libbitcoin_blockchain bc::chain::    blockchain (database impl)
libbitcoin_node       bc::node::     Full node w/Satoshi protocol
libbitcoin_server     bc::server::   Full node w/client-server protocol
libbitcoin_client     bc::client::   Client impl of c/s protocol
libbitcoin_explorer   bc::explorer:: Updated version of SX

Notice that each lib (except libbitcoin) has a primary namespace within
bc and the new header convention matches that hierarchy and
nomenclature. Since libbitcoin exposes the root namespace for all others
(bc) its more of a parent than a sibling. This is consistent in the repo
names as well. But it is really not desirable to maintain this hierarchy
in terms of file system organization. In other words, we don't want the
other libs organized *within* the libbitcoin implementation's directory
structure (since it would preclude independent repos).

So libbitcoin is currently special, not a sibling library. We could make
it not special by calling it something like libbitcoin_system and
changing its namespace to bc::system. That would be very consistent. The
downside, if any, would be verbosity (in namespace references) and in
the lack of a single repo we could refer to as "libbitcoin". I'm not
sure system would be the perfect name, but the organization would be
perfectly rational.

On the other hand, since it's a dependency of all other repos and we
probably like the idea of a "libbitcoin" repo, we may want to just keep
it "special". In that case I would recommend keeping the name of the
header as bitcoin.hpp, matching the namespace. Introducing a name for
the header that doesn't match the repo name and doesn't match the
namespace name is IMO introducing confusion without benefit.

Either of these options are reasonable and in terms of preference I lean
towards the first, which is the current implementation:

libbitcoin
<bitcoin/bitcoin.hpp>
bitcoin:: (or bc:: for short)

libbitcoin_system
<bitcoin/system.hpp>
bitcoin::system:: (or bc::system:: for short)

e

On 09/24/2014 11:11 AM, Amir Taaki wrote:
> Well it also include utilities which is important to note.
> Things like hashing or crypto functions.
> Eric has also merged libwallet back into libbitcoin main under
> include/bitcoin/bitcoin/wallet/
>
> On 09/24/2014 07:10 PM, William Swanson wrote:
>> I like this idea. That way, the top-level "#include <bitcoin>"
>> directory is pure library-level headers, with all the sub-headers in
>> their own directories. The names "core" and "system" are both fine,
>> but "base" or "types" could also work.
>>
>> The name "types" is nice, because it makes it clear that this library
>> is designed to provide the basic data types that bitcoin is built
>> from. The actual functionality goes in the other libraries, like
>> blockchain or network.
>>
>> -William
>>
>>
>> On Wed, Sep 24, 2014 at 10:56 AM, Amir Taaki <genjix@???> wrote:
>>> hey,
>>>
>>> so we're reorganising libbitcoin into submodules like blockchain,
>>> server, node, ...
>>>
>>> there's a 'bitcoin' submodule which is the current main code in libbitcoin.
>>>
>>> Would it make sense to rename this to core? or system?
>>> So instead of:
>>>
>>> #include <bitcoin/bitcoin.hpp>
>>>
>>> We have either of:
>>>
>>> #include <bitcoin/core.hpp>
>>> #include <bitcoin/system.hpp>
>>>
>>> I kinda like system for what it implies.