[Battlemesh] WBMv8 -- a personal perspective

[Daniel Golle]

Hi everyone!

On Sun, Aug 09, 2015 at 10:01:33PM +0200, Juliusz Chroboczek wrote:
> Hello,
> 
> First of all, many, many thanks to Musti and the other organisers of WBMv8
> in Maribor, Slovenia.  This was very well done.
> 

Full ACK!


> Suggested improvements
> ======================
> 
> No event is so perfect that it cannot be improved upon, and WBMv8 is no
> exception.
> 
> I thought many talks were too long -- everyone got a one hour slot, while
> many of the talks could have been done just as well in 30 minutes or so.
> (I originally asked for 40 minutes for my Babel talk, but got one hour
> anyway.)  I also thought there were many talks that were not clearly mesh
> related -- I think we should have a rule that says "if it's not mesh
> related, you get 15 minutes, and we'll interrupt you rudely if you go over
> your allotted time".  (And if you intend to sit down and scroll a text
> file rather than preparing a proper set of overhead slides and speaking to
> the audience, you get 0 minutes.  Sorry.)

I prepared my text-mode presentation knowing that it'll take about 20
minutes to scroll through it and would have been fine with a 30 minute
time-slot, which would have only limited the question round (I did
try to focus on community-mesh-relevant topics and postponed all
general GNUnet-related questions to private sessions after the talk)

If there (apart from formalities) was anything fundamentally wrong in
the slides http://battlemesh.org/BattleMeshV8/GNUnet-slides or the
talk itself, I'd be happy to know (question to everyone).

I decided on purpose not to apply the normative rules of how things
should be marketed and presented (longer discussion, happily having it
with anyone on- or off-list). If that was perceived as an offense,
I ask for your apology and would be happy to improve where ever there
are sound arguments. Please do contact me directly if there is anything
you believe I should learn.

I can see how future versions of the battlemesh could have several
tracks, eg. a routing track, a more general distributed systems track
and a community/social/politics track. Possibly IoT/sensor-net-related
topics will also be popping up in the not too distant future.

> 
> [...]
>
> Somebody bullied Federico into adding Gnunet to the firmwares at the last
> moment.  Folks, that's not how it is done -- last minute additions are not
> acceptable, no matter how good your sales pitch.  Thanks to the cjdns and
> MaidSafe people for their restraint.

I probably won't make you happy by telling you that I also did help to
get cjdns into OpenWrt/routing and Lars had cjdns added to the
WiBed as well. Having Rust rolling in OpenWrt and getting MaidSafe
packaged is next on my agenda...

Anyway, to me it seems like I must have really pissed you off:
You are saying that somebody (and that would probably be me) bullied
Federico into including GNUnet in the firmware build.
If this is really how Federico and you perceived my attempt to make
measurements of GNUnet's routing algorithm (CADET) using WiBed, I ask
for your appology. I by no means meant to disturb or bully anyone into
anything.
I interacted with the testbed team a lot in the first few days and
asked about the right way to get GNUnet's packages built for the
WiBed firmware, so they could later on (supposedly once all other
tests would have run) be used to install GNUnet on the external
USB overlay filesystem.
The answer I was given was to fork wibed-battlemesh-experiment and
create a pull-request on Github, which is what I did. I didn't expect
that pull-request to be merged without consent of everyone in charge
nor did I intent to push anyone into merging it.
I did spend quite a lot of time before the event to get GNUnet packaged
for OpenWrt and made sure that including it at compile-time or having
it installed but disabled will have no negative effects (apart from
space usage). If including GNUnet in the build actually did cause
problems, I'd be very glad to know them since I should then be working
on fixing the packaging, obviously. So please let me know, I promisse
not to bite.

I also managed to get some measurement results using a small-scale
testbed I built using some spare devices Simon had brought because
once I realized that there were several "forks", I wanted to make
sure to at least be able to test some things independently of WiBed,
also because I understood the need of "the four/five" to get their
stuff tested without having to bother with more immature or less
traditional protocols.

This whole discussion about what and what not to *build* could have
been avoided easily by either using an official OpenWrt release
(-candidate) or by generating an SDK for the testbed firmware
available to everyone to build their packages on top of that.


Anyway, the results I got do give a very good picture of how GNUnet
performs on small embedded systems (very bad, not very surprisingly).
Overall, I'm still very happy with this and thank everyone who helped
to evaluate yet another cryptographic routing protocol during the past
week!
This helped to empirically point out severe design flaws around
GNUnet's roll-your-own-event-library and did generate very helpful
feedback for the actual GNUnet developers (I'm just a packaging monkey
contributing to OpenWrt/packages, one of my personal goals is to get as
many distributed applications to run on small embedded systems as
possible)


Maybe see you next year!


Cheers


Daniel