You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
@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.
Activity
TcM1911 commentedon Jan 15, 2015
I think this would be a great idea.
stevedekorte commentedon Jan 15, 2015
I agree. Btw, we've made a Bitmessage framework that can help those writing OSX clients:
https://github.com/Voluntarynet/BitmessageKit
scrobbleme commentedon Jan 31, 2015
+1
bartmika commentedon Feb 13, 2015
+1
goldbook commentedon Feb 16, 2015
+1
TheNain38 commentedon Oct 23, 2015
+1 It would be usefull if other projects wants to use Bitmessage core without having a UI
PeterSurda commentedon Oct 23, 2015
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 commentedon Oct 23, 2015
@PeterSurda Is it possible to compile it without GUI? Just to use it through the API?
TheNain38 commentedon Oct 23, 2015
@PeterSurda Forget what I just say, I didn't seen daemon mode
stevedekorte commentedon Oct 23, 2015
@TheNain38 Yes, we do this for our Bitmessage client (BitPost).
stevedekorte commentedon Oct 23, 2015
Bitchan looks like a great project. Is the Bitmessage support working well?
mailchuck commentedon Oct 23, 2015
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 commentedon Oct 23, 2015
I was referring to a GUI/core separation
bartmika commentedon Oct 24, 2015
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.
PeterSurda commentedon Oct 24, 2015
Since there appears to be demand, I'll take a look at it, but it won't be anytime soon.
TheNain38 commentedon Oct 24, 2015
@PeterSurda thank you
TheNain38 commentedon Oct 24, 2015
If you port Bitmessage to python 3.4, it would be good to also keep 2.7 compatibility
bartmika commentedon Oct 24, 2015
@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!
TcM1911 commentedon Oct 24, 2015
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.