Separate BM core and GUI client #739
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-05#739
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
I think this would be a great idea.
I agree. Btw, we've made a Bitmessage framework that can help those writing OSX clients:
https://github.com/Voluntarynet/BitmessageKit
+1
+1
+1
+1 It would be usefull if other projects wants to use Bitmessage core without having a UI
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.
@PeterSurda Is it possible to compile it without GUI? Just to use it through the API?
@PeterSurda Forget what I just say, I didn't seen daemon mode
@TheNain38 Yes, we do this for our Bitmessage client (BitPost).
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.
Bitchan looks like a great project. Is the Bitmessage support working well?
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.
I was referring to a GUI/core separation
This ticket and porting bitmessage to Python version 3.4 are my two wish list items I'd love to see done for future releases.
Since there appears to be demand, I'll take a look at it, but it won't be anytime soon.
@PeterSurda thank you
If you port Bitmessage to python 3.4, it would be good to also keep 2.7 compatibility
@PeterSurda thank you! I love building little apps for PyBitmessage as this technology is fascinating. I've already built https://github.com/bartmika/bitmessage-answeringmachine and I have some other interesting ideas I'd like to build. But the problem is all the development work I do now is only in Python 3.4 and I'd like to have PyBitmessage headless run (without GUI but only core) so I can focus on developing apps with it. That's why these two items are on my wishlist. Thanks for reading and wishing all the best!
I think it would be a good idea of separating the GUI and the core into two different repos, having the core live maybe under Bitmessage/libbitmessage or something similar. Doing it this way, the lib can serve as the reference implementation of the protocol.