Why there are so many alternative Bitmessage implementations?

[chan3] bitmessage
May 6 13:48 [raw]

The answer is easy: PyBitmessage is completely unusable for anything but default use case. It's a hard challenge to embed it into your application. It doesn't provide a sufficient API to create a primitive web interface. It has no facilities to access the wire protocol. You can't just decrypt messages in your application without reinventing the already written code. So what is needed is to divide PyBitmessage to reusable parts. Message encoding and decoding can be moved to a separate library. API needs methods to manage peers and send wire level messages. Ideally API must provide everything necessary to reproduce the GUI. These improvements can reduce the need for alternative implementations. Provided they will be documented or at least mentioned on the same wiki page along the API. And no, I don't know who should do it.

[chan] bitmessage
May 6 13:50 [raw]

idiot. there is bmf and the new web i/f ure fucking clueless

[chan] bitmessage
May 6 14:18 [raw]

Make Delphi-based bitmessage.so and bitmessage.dll to make Bitmessage great again.

[chan] bitmessage
May 6 14:31 [raw]

Thanks for your message. Many of the suggestions below make a lot of sense, and some of them are being worked on as we speak. Please be patient and keep communicating your suggestions/requirements articulately (the way you just did), they are being listened to.

[chan] bitmessage
May 6 14:40 [raw]

huh ? using API or not, already u can peg away and make a new GUI reusing BM code, by just calling the py functions etc. I dunno what the guy wants

[chan] bitmessage
May 6 15:24 [raw]

My understanding is that OP wants a rich, stable and documented interface with no risk of breaking interop on every release (reusing code doesn't qualify). Yeah, what do you want, OP? :)

BM-NB4UTyuEJrQBtxJfT96DVagfQo8ZaeoN
May 6 20:57 [raw]

I agree with some of these points. Bitmessage could be modular with each independent piece functioning independently and communicating to the other modules. The API is useful but too constricted. It could have low level commands for manipulating every aspect of every module. Gateway modules to other protocols should snap in like plugins. Each new plugin could add its own API command layer to the API, so the API responds by redirecting requests to the appropriate module, and the module will process the API request. This relieves the Bitmessage Core from needing to document everything--module maintainers would document their own modules. For instance if I wanted to add a RSA encryption layer for messages, I would write a module and supply the documentation. End user would install the module and have RSA encryption added with the docs. Connecting via I2P provides another example. Instead of factoring Bitmessage Core to negotiate I2P protocol, the separate module contains the logic and libraries for that. The user installs the module and now has a Bitmessage that bridges Bitmessage network and Bitmessage over I2P. Tor gateway could be refactored the same way as a plugin. = zaeon =

[chan] bitmessage
May 6 22:03 [raw]

Yup same deal for ricochet. It's a Qt GUI app from top to bottom. It needs to be a ricochet library with an optional GUI component.

[chan] bitmessage
May 7 02:11 [raw]

There's a lot of truth in this message.

[chan] bitmessage
May 7 07:18 [raw]

how did the zeronet folks get to use BM then , Mr Clueless ?

[chan] bitmessage
May 7 07:23 [raw]

Yeah! There's a lot of ways to customize PyBM ... it's just getting people to actually do it!

[chan] bitmessage
May 7 10:30 [raw]

refactoring stuff would not be my priority adding new functions can be done right now with BM as it is

[chan] bitmessage
May 7 18:29 [raw]

> adding new functions can be done right now with BM as it is adding new functions locks in PyBitmessage GUI and moves further away from modularity.

[chan] bitmessage
May 7 18:31 [raw]

true but I say fuck it. work with what you've got. the zeronet guys did not fuck around like those shills...

[chan] bitmessage
BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY

Subject Last Count
PyBitmessage Security Scan on Branch v0.6 Jun 18 05:43 58
unpickling knownnodes to a readable format Jun 18 04:43 27
ERROR - Too many items in inv message! Jun 18 04:26 10
WARNING - Probably wrong category number in playSound() Jun 17 09:41 1
onionscan update Jun 17 03:47 6
Inbox bug Jun 16 20:38 4
Integration with GPG (GnuPG) Jun 16 17:13 3
I don't receive any BMs when I have only one peer. Jun 16 17:13 6
test Jun 16 09:37 3
identicon code bug? Jun 16 06:35 1
attack? Jun 16 04:23 2
Free Git Replacement Jun 15 17:31 8
github Jun 15 04:35 1
Latest git pull: inbox doesn't update Jun 15 03:55 4
IPFS Jun 13 21:48 8
latest in the spy world Jun 13 19:14 2
(no subject) Jun 13 19:12 3
TIMESERVICE Jun 13 19:05 1
Questions about BM nodes Jun 12 22:53 7
D2A41B229F7BCE6F9B429D3E33A47598 Jun 12 22:26 1
Why not reject old clients from connection to the network? Jun 12 19:18 10
Add an option to connect only to onions Jun 12 00:42 2
Help Improving Algorithm Jun 11 23:48 3
hey - why not make pyBM as shitty as "Signal-App" by Marlinspike ? Jun 11 21:53 1
Silence debug.log foe less disk-write Jun 11 14:44 4
Questions about "Max acceptable difficulty" Jun 11 04:24 2
"Post to BM" API Jun 10 12:11 5
"Configuration NOT changed" Jun 10 09:41 2
Error/Warnings in debug log: Should I worry? Jun 10 09:34 1
Bitmessage Security Test: ZWD attempt Jun 10 08:05 1
bitmessage inaccessible Jun 10 08:04 1
mailchuck.com email gateway Jun 10 07:47 3
Microsoft owns GitHub Jun 9 15:23 1
NIST key management guidelines suggest that 15360-bit RSA keys are equivalent in strength to 256-bit symmetric keys… Jun 9 11:25 12
Cloudflare MITM blocker Jun 9 11:21 4
GitHub Jun 9 11:16 15
Improvement of Trustedpeer setting Jun 6 06:26 2
blank blank blank Jun 6 06:26 5
is multiple trustedpeers possible? Jun 6 01:00 7
Bitmessage Documentation Bug Jun 2 10:09 4
REAL security experts endorse "security by obscurity" May 31 13:22 7
TRUE LOVE May 31 06:38 1
PyBitmessage Security ... Security Levels May 30 04:56 2
How to force BM to use only .onion nodes? May 30 04:56 15
Dread May 29 16:31 1
6F3F2CF9891928A25B71BBC4707B8753 May 29 10:56 1
SMTP and IMAP integration in the client May 29 06:21 5
Bitmessage Wiki Blocked May 29 00:51 12
Desiderata May 28 20:07 2
Bitmessage Bug May 28 17:15 2
I solved the Bitmessage Captcha Puzzle! May 28 08:56 2
setup trusted peer question May 28 08:05 6
bitmessagemain from pyinstaller executable won't run May 28 07:41 4
help with messages.dat May 28 07:36 7
Roll Your Own Crypto! May 28 07:06 6
look closely May 27 18:33 5
How to use chan alt.anonymous.messages May 27 08:21 2
feature request May 27 01:34 10
YOU WANNA HIRE A LEGIT HACKER????? May 26 04:39 5
Security Test on PyBitmessage Branch Master May 26 00:11 1
#2 May 25 22:41 6
minimum difficulty for chans May 25 16:45 16
BM-2cWkFSxB4cyeNVr99tgJdkMA2nfivbXLiH May 25 07:07 2
ein kleines pyBM Nebenproblem in KDE LiquidShell May 24 18:14 1
PyBitmessage 0.6.3.2 blacklist whitelist May 24 06:29 6
Test DML May 24 02:18 1
Now, following my own advice, adding channel bitmessage and general to the blacklist May 23 15:50 5
hyperboria node [fc5b:acf7:9762:439c:394d:02bb:d603:05de]:8444 May 23 01:34 3
Feature request: delete all messages from user May 22 10:46 2