Why there are so many alternative Bitmessage implementations?

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.

May 6 13:50 [raw]

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

May 6 14:18 [raw]

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

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.

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

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? :)

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 =

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.

May 7 02:11 [raw]

There's a lot of truth in this message.

May 7 07:18 [raw]

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

May 7 07:23 [raw]

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

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

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.

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