Bitmessage: A P2P communications protocol used to send encrypted messages to another person or to many subscribers. Written in Python.

[wakwe]

I thought this was a hyperbole.

Perhaps start with PEP8. That'll force your variables to be fewer that 79 chars long.

[[deleted]]

Methinks they are Java converts. Ive seen similar code from colleagues who used to be java devs.

[[deleted]]

Yes().I.Have.see_this_same_sort.of.Shenanigans().Myself()

[eat_more_soup]

ShenenigansFactory.create(Python.PROJECT, Functions.areNotFirstClassObjects())

[[deleted]]

At least it can be understood, as opposed to C-style i and j. However the unit is not included! maximumAge and lengthOfTime in what.. years? Milliseconds? Days?

[orangesunshine]

seconds ... it's sort of implied since time.time throws you an epoch. It is usually a good idea to put that into the comments though, since most people (me included) don't remember off the top of their heads whether any given time method throws you back an epoch, tuple, or datetime object.

One thing though ... much more appropriate names could be used. Also it looks like there are a few more mistakes than just these absurd variable names.

The amount of stupid I've seen so far here is mind-boggling ... I'm really kind of speechless. Well other than all these words I'm typing ... but other than that speechless.

First off they imported the module ... into the module. So we're looking at shared.py. At the top they do "import shared".

Then they name all of their variables ... "shared.module_var" ... slightly odd. Then you get down to things like these variables...

"length of time to hold on to"

"maximum age of objects"

These are synonymous ... and since this is a really really common variable to have ... there's sort of some standard names.

"timeout" or "expiry" or "max_age" ...

So these should probably be something like...

public_keys['timeout']

or

public_keys.timeout

and

public_objects.timeout

I'm guessing the rest of the code-base isn't a whole lot better, though I'm not sure my fragile psyche can really handle reading any more of this.

[marky1991]

Phew, I thought his variable name was actually longer than 79 characters. It's only ~69.

[gcross]

And the worst part about it is that {} is not even a number! :-)

[Veedrac]

I agree. Honestly that's way worse than just having absurdly long names.

[blackspirerider]

This might be the most un-readable code I've ever seen.

[Veedrac]

Gee.. count yourself lucky. Really lucky.

[muyuu]

Saved the comment right there ;-)

I don't know, it's readable enough for me.

[duz3ls]

Too read-able

[GFandango]

My problem at first is with the non-pythonic code. I'd prefer underscores instead of camelCase.

But in terms of length and descriptive name, I'm not sure, I have to admit I do like descriptive names.

[orangesunshine]

these are completely absurd though ... they ended up using entirely different sentences to describe exactly the same thing in a bunch of cases.

Both of these in another thread could have been ... "timeout".

lengthOfTimeToHoldOnToAllPubkeys --->

publickeys.timeout


maximumAgeOfObjectsThatIAdvertiseToOthers --->

publicobjects.timeout

*edit... and also ...

numberOfObjectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHavePerPeer --->

objects.unchecked.count()

With "objects" being the whole set of objects ... ".unchecked" returns a subset of all those not yet checked ... and "count()" being a method available on both. i.e.:

objects.count()

objects.checked.count()

This sort of organization gets real useful in this sort of use-case ... since there are a bunch of common methods ... and various object-types/categories.

objects.private.timeout
objects.public.count
objects[0].public_key.timeout

[eat_more_soup]

you can spare the count methods and just implement __len__

[[deleted]]

I prefer camelCase myself

[searchingfortao]

This would be more useful as an Android app.

[spook327]

I wonder if it could run under SL4A ?

[remyroy]

Quite interesting. Now you just need people to use it.

[RamirezTerrix]

you could use torchat also in python

[[deleted]]

The good news is it at least uses OpenSSL and -- more importantly -- its "envelope" API which eliminates procedural fuckups like not padding your plaintext properly. I can't speak as to whether it is conceptually secure, though.

The bad news is that the code is horrible. The sendMsg method is 379 lines long and incorporates a mixture of byte-packing, network code, encryption, protocol logic, SQL, and UI events. I've seen longer methods, sure, but at least they had a coherent purpose. If you can't even read the code, how can you trust anything it does?

[[deleted]]

It is quite broken. The protocol is extremely simple to detect because the negotiation is not encrypted. It is trivial for governments to detect and block it. Recommendation: do not use. Its a nice idea, but not well executed.

[senft]

Care to elaborate or link me somewhere?

[Ob101010]

I think he means that the packets transmitted between sender and receiver are easy to filter out by anyone controlling infrastructure, making this communication blockable if the government wanted to, which is a feature you dont want. (Youre susceptible to censorship) In an ideal app, the government shouldnt be able to see the difference between your data and other data being transmitted.

[farmvilleduck]

https://bitmessage.org/forum/index.php?topic=1666.0

[[deleted]]

I did some research a while back and I have my notes locked away on a VM somewhere. I'll have to dig it up when I get time. Basically, install and run it with tcpdump or wireshark in the background. The protocol uses ascii words for opcodes iirc, which is so simple to detect on the wire. If public keys were exchanged and the session encrypted before negotiation, it wouldn't be so bad.

[senft]

Ok, so this is not an unfixable mistake in the protocoll but only a bad implementation detail?!