zzz.i2p

Everybody should assume Bote is dead abandonware. You can stop asking about it.

The previous maintainer, str4d, is totally unresponsive to our queries.

There's numerous reports that it doesn't work any more. There's 50+ unresolved tickets, most open for several years. It doesn't support secure signature types introduced in I2P over 6 years ago.

It's a large, complex code base with dozens of dependencies. Nobody on the I2P team wants to work on it. The team did attempt to assign people to work on it, but due to disinterest, bad match of skills, low priority, and loose project management, almost nothing happened.

Some have asked for us to bundle (un-pluginize) it, that's impossible due to the bote license restrictions, and doesn't address the maintenance issue.

str4d moved it from monotone to github 3 years ago under the (widely held) theory that monotone prevents new developers from joining, and that with that barrier removed, contributors would flock to the project. That hasn't happened. There's zero new contributors, and a total of 4 (ignored) PRs in 3 years.

Back in 2006, jrandom stopped working on the core I2P router to work on Syndie, a secure and anonymous messaging platform. At the time he stated that messaging was the core use case for I2P. That without a solid messaging product we would not succeed. Syndie was always problematic, and when jrandom stopped working on it (and then vanished), it wasn't going to become big. Even though I spent quite some time working on it afterwards.

Bote was started by HungryHobo around the same time. The protocol is documented, but I don't know if it was ever reviewed by anybody for security, or choice of crypto algorithms. It is well documented and at a high level seems to be well-designed. A few years later, HH had health problems if I recall, and vanished. str4d eventually picked it up and did an enormous amount of work on it. But like every single thing he used to support, it's now abandoned, and he won't talk to any of us any more, on any topic, for any reason.

Both syndie and bote were started before the sharp rise of social media platforms, and they both seem antiquated today. I don't know what a modern, secure, distributed, anonymous messaging platform would look like if we started from scratch today. Without these applications, we're left with two primary, decades-old platforms - email and IRC.

We have had big success with mattermost (a slack-like platform) internally. It's quite usable over I2P even though most of the team does it over clearnet, can't be bothered with dogfooding. There are outstanding anonymity and efficiency/performance issues with mattermost that have not been resolved nor reported upstream.

We have also talked about bundling a javascript IRC client into the console but initial investigations show that it could be quite difficult. We added comments to i2psnark a couple years back, not widely used. Zab added IRC-like functions to MuWire.

The last time the team talked about it, we agreed that messaging is still a key to i2p's success. We don't know exactly what that would look like, but it's not bote. From our experience with modern social media platforms, and with mattermost, it's clear that attachments, especially images, is a requirement, as is low-latency. Bote and syndie were very high latency, by design. Image attachments is a fantastic feature but image sharing on open platforms is problematic in anonymous networks for the usual reasons.

There has also been a proposal within the team to completely rethink / redesign susimail, and combine it with bote. That's problematic for a number of reasons - not our core expertise, 10 times harder than just maintaining bote (which nobody wants to do), the bote license issues... and nobody has a clear vision of what it would even look like. If it were me I'd rewrite the low-level parts of bote from scratch (cleanroom from the docs) and stick it in susimail. But others have strong opinions that susimail is a complete dumpster fire of a UI and that's what should be thrown out. Either way it's a horrible shotgun wedding. And a total fantasy given our current resources. I don't understand the "I don't want to maintain X but I'd be happy to rewrite it from scratch" mentality but it is common. With even minimal control over how we allocate our resources, it shouldn't happen. But we'll see.

So I don't know what the answer is, but it's clear that it's not bote. You all can stop holding out for it.

Last edited: Thu, 05 Mar 2020, 02:50pm by zzz

Thank you for clarifying the bote status. I have been fairly active asking for a fix, but now that I have read this posting I now know that it is dead. I also thank you for the in depth background because I have learned how all of this has come about. Also, it sheds light on the mind set of the development community. As a positive note, I have been motivated and inspired to become a coder. I have been studying hard and will contribute to the i2p project as soon as I get the skills needed for the task.

Thank you again, zzz.

quark

IRC Jan. 19 wrote:

<polistern> Hi everyone! Can somebody help me with my questions about Java Bote?
<dr|z3d> bote is on life support, polistern, but ask away.
<polistern> Will the application be supported by the I2P project or is mhatta the only hope now?
<dr|z3d> mhatta is currently the only person working on bote, and I don't think he's done much lately.
<dr|z3d> I put some themes together a few years ago, but I haven't looked at the codebase in a couple of years.
<dr|z3d> what you probably already know is that there's a lot of cruft in the codebase that needs either removal or updating.
<polistern> In any case need to make changes to the protocol.
<polistern> Well, I'm trying to keep my Bote client backwards compatible with Java, and I'd like to know if this is justified.
<dr|z3d> that's a good question, to which there is no easy answer. all depends whether mhatta intends to maintain bote. it's not clear what his intentions are.
<eyedeekay> In any case if mhatta were to start maintaining bote again, we would need help from us as well
<polistern> For basic functionality only small edit in the Bote protocol is enough to work with new types of addresses in I2P.
<polistern> More precisely in the processing of one type of packets.
<eyedeekay> That I can probably handle, and I guess I have plugin signing keys now...
<eyedeekay> Which type of packets?
<polistern> Peer List
<polistern> Here is the exact change I made: https://pboted.readthedocs.io/en/latest/bote/v5...
<polistern> Now if Java Bote first runs on I2P node and get non-DSA key, then it can only send mail and can't recieve.
<polistern> Because in protocol version 4 I2P addresses can only be of a certain length (384).
<polistern> But what is interesting, even with all this, there are about 200-250 live nodes in Bote network :)

<eyedeekay> I think I'll be able make the necessary changes but without mhatta I won't be able to release an update to existing Bote's
<eyedeekay> If I come up with something I'll try to get mhatta's attention and merge it
<eyedeekay> It would essentially become another life-support fork

200-250 nodes is at least 10x more than I would have guessed. That would make it our most popular plugin by far.

A few months ago I talked to polistern and looked at her proposed protocol change. It's straightforward and obvious and would be easy to implement in the plugin... at least handling of the longer dests.

The harder part is dealing with the protocol version number... talking version 5 to version 5 peers, version 4 to version 4 peers, omitting the peers with longer dests from the version 4 messages, lying to version 4 peers about being version 4. And of course testing all of it.

All doable though.

Presumably mhatta is still unresponsive; the solution would be to sign the new plugin with our own keys, and getting the word out to everybody that they have to delete and re-add the plugin, perhaps with instructions on how to preserve their data. Of course that's what mhatta did, but he never did an effective job of communicating the issue with signing keys.

If we do touch it and decide to own it, we'd need to review the boatload of other issues, some mentioned in OP above.

As usual, all about priorities. If the current user base really is that big, might be worth some attention.

Hi everyone!

zzz, thank you for joining the resurrection of I2P-Bote

In case anyone is interested, I will describe the hack that I use in to communicate with nodes:

* Version 4 nodes can accept messages from version 4 and above, but only respond with version 4 packets.
* Version 5 nodes send version 5 requests packets, but process the response, which may come as version 4 or 5 packet.
* The hypothetical version 6 will have the same capability if we keep the existing version checking mechanisms.

This feature allows us to organize a smooth migration to new version of the protocol.

Will only one packet be changed in I2P-Bote (as in pboted at the moment) or will protocol 5 be fully implemented after discussion?

Thanks

Unfortunately, we have not yet found any resources or volunteers to do this work.