I noticed that the subdomain dev.libre-mesh.org runs with a self-signed
certificate, which is annoying because casual people browsing (and
security paranoid) won't accept to add an exception in order to read
more and will leave...
A free browser-accepted certificate can be obtained from StartSSL 
(for that specific domain, wildcards and extended verification certs are
not for free of course, but we there is no need for them).
We should endorse too!
What do you think?
---------- Forwarded Message ----------
Subject: [Battlemesh] V8 Current Endorsements
Date: Sunday, February 15, 2015, 05:38:25 PM
From: Nemesis <nemesis(a)ninux.org>
To: Battle of the Mesh Mailing List <battlemesh(a)ml.ninux.org>
This is the current endorsers list:
* Wlan Slovenia (host)
* Wireless Leiden
So far we already have all the logos of these from last year.
Somebody else wants to come on board right now and save us some time
needed to reach?
As to sort raw intormation about the lime systems, we did start a dokuwiki
If things go well this might be transfered to any official libremesh docu
We would appreciate any form of ideas,help or cooperation.
>Did you already read this ?
yes, we took this as a start for the analysis
>btw lime-default options are readed in case of something missing from lime
1.is there any "override" mechanism to stop lime-config touching
original config files or params within ?
2. overall view of the design "/usr/bin/lime-config" ( lua script
with no "lua" extension ?)
3. list of keywords used in "/usr/bin/lime-config" and respective
scripts / files
4. there is some "mingle" between lime and lime-defaults - whats the
meaning of "missing" compared to what.
Next halt : Parsing of lime / lime-defauls and the respective list of
keywords with their actions have to be carved out of the source
btw : we have been really surprised by the numbers of interfaces been
generated and digging deep to find out to which extent they are
necessary and to what use
No organised site to store the documentation to ?
Yesterday I tested the current implementation of the web interface LUCI2
 (which will replace LUCI in the future). The basic administration
menu (Network, WiFi, System, Status, etc.) is already implemented and
LUCI2 is a 100% rewritten web interface and it does not use lua anymore.
ubus via standard JSON. So it is quite more flexible and less resources
aggressive for the router (since the JS is executed in the client side).
I would recommend to start thinking in LUCI2 instead of LUCI, so we
should base the future LiMe web interface in LUCI2. Would be nice to
/usr/bin/lime-config resp. /usr/lib/lua/lime:
as far we do understand these programs affect uci-config files in
/etc/config/ related to data in /etc/config/lime AND/OR
list of keywords and their lime-configuration-action ( complete list ?? )
config lime <lime config class>
<DNS ip ipv4>
override / prevail preset config-values
it would be very helpful for us and the project if anyone can shed a
profound light on this.
To trace the sourcecode for informations is too time-consuming, so we
wonder if there are any more documentation hidden somewhere.
We do believe, that a project like lime cannot survive without proper
system and user dokumentations and we are willing to start this.
Any kind of help is welcome