Separate BM core and GUI client

[hackergrrl]

Are there any plans or intention to separate the PyMessage GUI from the core bitmessage node? Tox does this nicely by maintaining tox-core separately from its myriad of clients. Given that the community has already demonstrated an interest[1][2][3] 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.

[TcM1911]

I think this would be a great idea.

[stevedekorte]

I agree. Btw, we've made a Bitmessage framework that can help those writing OSX clients:

https://github.com/Voluntarynet/BitmessageKit

[scrobbleme]

+1

[bartmika]

+1

[goldbook]

+1

[TheNain38]

+1 It would be usefull if other projects wants to use Bitmessage core without having a UI

[PeterSurda]

You can run pybitmessage without the GUI and access it through the API. There are two projects that create a bridge to email clients (https://github.com/Arceliar/bmwrapper and https://github.com/AyrA/BitMailServer) and one by me which creates a bridge to email servers, https://github.com/PeterSurda/bitmessage-email-gateway. Then there's an alternative implementation, https://github.com/monetas/bmd with an email bridge too, https://github.com/monetas/bmclient.

So you even have a choice between python, C# and go. It may not do everything you want, maybe an addon for Thunderbird would be nice, but I think that it's outside of the scope of this project so I'm closing the issue. If you want to help, help one of these other projects, or let me know what API calls you're missing. Adding new API calls should be fine.

[TheNain38]

@PeterSurda Is it possible to compile it without GUI? Just to use it through the API?

[TheNain38]

@PeterSurda Forget what I just say, I didn't seen daemon mode

[stevedekorte]

@TheNain38 Yes, we do this for our Bitmessage client (BitPost).

[hackergrrl]

There are two types of separation I think are being conflated: library / application separation, and api server / application separation.

Right now, PyBitmessage offers its network API as its own integration point. Contrast this with a library like bitchan/bitmessage, which implements solely the BM core, and delegates other orthogonal concerns (e.g. networking) to other libraries (in this case, bitchain/bitmessage-transports). This opens up brave new worlds of exploratory efforts: I can just swap out a default TCP transport with WebSockets or Bluetooth and reap the benefits! All without needing to do a hard fork on the entire codebase and GUI app.

This kind of effort decouples the components of BitMessage's functionality, giving a variety of integration points to prospective developers wishing to build on BM's technology. This lets the PyBitmessage GUI application live separately from the lower layers of the BM stack.

[stevedekorte]

Bitchan looks like a great project. Is the Bitmessage support working well?

[mailchuck]

The transport/core separation makes more sense and that is something I may consider for PyBitmessage, but not for the moment. However, GUI separation is a different issue. There isn't that much glue, the core sends some signals to the GUI, GUI sends messages to the PoW thread, and they share a database thread (because sqlite3 does not like multithreading). That's about it.

[TheNain38]

I was referring to a GUI/core separation