30 May
2017
30 May
'17
3:42 p.m.
Thinking about how we might use the voucher system for access control in
Caimito and other communities in the area...
1) I imagine the process might be that someone connects to the wifi,
opens a browser (or on Android, sees a notification to register on the
network, like in airports), gets caught by the captive portal, and has
an option to use the network without registering, or enter a voucher
code. Correct? Other options?
2) In order to make the voucher code as easy as possible to use, three
options occur to me:
-- 1) the code is 2 or 3 letters (maybe up to 6), case insensitive,
automatically generated by the system. (My favorite)
-- 2) the code is a word or pair of words, automatically generated by
the system. (My least favorite)
-- 3) the code is defined by administrator, and checked by the system to
avoid duplicate codes. (Maybe useful in some cases)
Letters instead of numbers because we get more options for each digit,
thus making a shorter code.
number of letters - unique codes:
1 - 26
2 - 676
3 - 17,576
4 - 456,976
5 - 11,881,376
6 - 308,915,776
Airlines tend to use 6 letters, and I can usually remember those codes.
With 2 letters, we could give unique codes to everyone who comes through
Caimito in a year, and with 4 letters we could cover 87% the province,
and with 6 we could give 19 codes to each person in Ecuador. I imagine
most community networks would be fine with 3 or 4 letters. Maybe the
length of the code can be defined by admin, or it can grow sequentially
as needed (first code is A, 27th code is AA, 677th code is AAA, so on).
3) Codes expire and get recycled, yes?
4) The vouchers are part of Pitbull, or separate-but-connected?
5) Probably "it'll be ready when it's ready, no later than October",
but... Any idea when a functional build might be ready? There are a
number of things that seem not feasible until this system works (e.g.
community library / internet cafe).
6) Can we define roles or profiles in Pitbull / the voucher admin
system? This way I can look at a list of currently active vouchers, and
see who's connected, how much time they have left, and whether they're a
library/network member, library visitor, tourist, or other. When I
create a tourist voucher, they get access to 50% of the available
bandwidth, and by default the voucher lasts 1 day. A library visitor by
default gets 90% access and lasts 1 hour. A member by default gets 100%
of bandwidth and 1 month.
7) When a voucher expires, keep the code reserved in the system for 10%
of the time it was valid, in case the person wants to renew the voucher.
Examples:
-- A 1 hour voucher of a library/ciber visitor expires, and they have a
6-minute grace period to request another hour on their voucher. The
admin interface makes extending the voucher easy.
-- A 1 month voucher has a 3-day grace period. The device doesn't have
access once the voucher expires, but renewing is easy: the admin doesn't
have to create a new voucher, and the person doesn't have to enter a new
code.
If there's a better place to share these ideas, please tell me.
~ Pato
31 May
31 May
4:47 p.m.
1) I imagine the process might be that someone connects to the wifi, opens
a browser (or on Android, sees a notification to
register on the network,
like in airports), gets caught by the captive portal, and has an option to
use the network without registering, or enter a voucher code. Correct?
Other options?
I agree, and the page where you enter the code should bring info about the
community, the network etc
2) In order to make the voucher code as easy as
possible to use, three
options occur to me:
3) Codes expire and get recycled, yes?
I think the codes should be long enough so that we keep creating them and
never have to recycle.
4) The vouchers are part of Pitbull, or
separate-but-connected?
They are part of it, and there is a neat menu page to add vouchers.
6) Can we define roles or profiles in Pitbull / the voucher admin system?
This way I can look at a list of currently active
vouchers, and see who's
connected, how much time they have left, and whether they're a
library/network member, library visitor, tourist, or other. When I create a
tourist voucher, they get access to 50% of the available bandwidth, and by
default the voucher lasts 1 day. A library visitor by default gets 90%
access and lasts 1 hour. A member by default gets 100% of bandwidth and 1
month.
Having some kind of status report would be aneat feature. And I saw this
idea of the personalized bandwidth in the issues list, they're onto it.
7) When a voucher expires, keep the code reserved in
the system for 10% of
the time it was valid, in case the person wants to renew the voucher.
Examples:
-- A 1 hour voucher of a library/ciber visitor expires, and they have a
6-minute grace period to request another hour on their voucher. The admin
interface makes extending the voucher easy.
-- A 1 month voucher has a 3-day grace period. The device doesn't have
access once the voucher expires, but renewing is easy: the admin doesn't
have to create a new voucher, and the person doesn't have to enter a new
code.
Are you thinking of an online payment system to get the vouchers? Then
perhaps the access to the merchant page could be always open (filter by
domain). Or the merchant page could be in the captive portal, which is
always accessible.
9:24 p.m.
On 05/31/2017 11:47 AM, bruno vianna wrote:
1) I imagine the process might be that someone connects to the wifi,
opens a browser (or on Android, sees a notification to register on
the network, like in airports), gets caught by the captive portal,
and has an option to use the network without registering, or enter a
voucher code. Correct? Other options?
I agree, and the page where you enter the code should bring info about
the community, the network etc
2) In order to make the voucher code as easy as possible to use,
three options occur to me:
3) Codes expire and get recycled, yes?
I think the codes should be long enough so that we keep creating them
and never have to recycle.
Why? For programming reasons? For ease of use in a particular case?
With 5 characters, that's probably enough (11,881,376), and with 7
definitely enough (8,031,810,176) to never repeat on that network.
Would it save processor energy on the router? Or maybe it would fill up
memory on the router?
4) The vouchers are part of Pitbull, or separate-but-connected?
They are part of it, and there is a neat menu page to add vouchers.
6) Can we define roles or profiles in Pitbull / the voucher admin
system? This way I can look at a list of currently active vouchers,
and see who's connected, how much time they have left, and whether
they're a library/network member, library visitor, tourist, or
other. When I create a tourist voucher, they get access to 50% of
the available bandwidth, and by default the voucher lasts 1 day. A
library visitor by default gets 90% access and lasts 1 hour. A
member by default gets 100% of bandwidth and 1 month.
Having some kind of status report would be aneat feature. And I saw this
idea of the personalized bandwidth in the issues list, they're onto it.
7) When a voucher expires, keep the code reserved in the system for
10% of the time it was valid, in case the person wants to renew the
voucher. Examples:
-- A 1 hour voucher of a library/ciber visitor expires, and they
have a 6-minute grace period to request another hour on their
voucher. The admin interface makes extending the voucher easy.
-- A 1 month voucher has a 3-day grace period. The device doesn't
have access once the voucher expires, but renewing is easy: the
admin doesn't have to create a new voucher, and the person doesn't
have to enter a new code.
Are you thinking of an online payment system to get the vouchers? Then
perhaps the access to the merchant page could be always open (filter by
domain). Or the merchant page could be in the captive portal, which is
always accessible.
Money in Caimito is all cash, with an occasional check, and no cards or
online payment so far. I can imagine some tourists paying by card or
some online system if it were available. Some (maybe most) of the people
here don't even have bank accounts (beyond the Caimito community bank).
I can imagine a community currency being created and used to pay for
Internet access.
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
1 Jun
1 Jun
2:49 p.m.
3) Codes expire and get recycled, yes?
I think it would be easier if you don't have to keep track of expired
vouchers, but I guess it's question for the coders.
I think the codes should be long enough so that we keep creating them
and never have to recycle.
Why? For programming reasons? For ease of use in a particular case?
With 5 characters, that's probably enough (11,881,376), and with 7
definitely enough (8,031,810,176) to never repeat on that network.
Would it save processor energy on the router? Or maybe it would fill up
memory on the router?
7) When a voucher expires, keep the code reserved in the system for
10% of the time it was valid, in case the person wants to renew the
voucher. Examples:
-- A 1 hour voucher of a library/ciber visitor expires, and they
have a 6-minute grace period to request another hour on their
voucher. The admin interface makes extending the voucher easy.
-- A 1 month voucher has a 3-day grace period. The device doesn't
have access once the voucher expires, but renewing is easy: the
admin doesn't have to create a new voucher, and the person doesn't
have to enter a new code.
Are you thinking of an online payment system to get the vouchers? Then
perhaps the access to the merchant page could be always open (filter by
domain). Or the merchant page could be in the captive portal, which is
always accessible.
Money in Caimito is all cash, with an occasional check, and no cards or
online
payment so far. I can imagine some tourists paying by card or some
online system if it were available. Some (maybe most) of the people here
don't even have bank accounts (beyond the Caimito community bank). I can
imagine a community currency being created and used to pay for Internet
access.
3 Jun
3 Jun
10:58 a.m.
Hi guys,
Thank you for your input.
For this project we are following an emergent design.
The idea is to have the bare minimum implemented for communities to install and uninstall,
enable and disable... So we can work together through experimentation to find out the most
valuable features and make them added earlier.
We are focusing on some community networks... If your community wants to participate on
the design process, please right to me in private and tell me about the community. That
will allow us to prioritize.
Bruno , great that you want to contribute by coding... Let's talk in private, shall
we? So we can organize ourselves,
On June 1, 2017 5:49:03 PM GMT+03:00, bruno vianna <bruno(a)pobox.com> wrote:
up
3) Codes
expire and get recycled, yes?
>
>
> I think the codes should be long enough so that we keep creating
them
and never
have to recycle.
Why? For programming reasons? For ease of use in a particular case?
With 5 characters, that's probably enough (11,881,376), and with 7
definitely enough (8,031,810,176) to never repeat on that network.
Would it save processor energy on the router? Or maybe it would fill memory on the router?
I think it would be easier if you don't have to keep track of expired
vouchers, but I guess it's question for the coders.
>
>
> 7) When a voucher expires, keep the code reserved in the system
for
> 10% of the time it was valid, in case the
person wants to renew
the
> voucher. Examples:
> -- A 1 hour voucher of a library/ciber visitor expires, and they
> have a 6-minute grace period to request another hour on their
> voucher. The admin interface makes extending the voucher easy.
> -- A 1 month voucher has a 3-day grace period. The device
doesn't
> have access once the voucher expires, but
renewing is easy: the
> admin doesn't have to create a new voucher, and the person
doesn't
> have to enter a new code.
>
>
> Are you thinking of an online payment system to get the vouchers?
Then
> perhaps the access to the merchant page could
be always open (filter
by
> domain). Or the merchant page could be in the
captive portal, which
is
> always accessible.
>
> Money in Caimito is all cash, with an occasional check, and no cards
or
online payment so far. I can imagine some
tourists paying by card or
some
online system if it were available. Some (maybe
most) of the people
here
don't even have bank accounts (beyond the
Caimito community bank). I
can
imagine a community currency being created and
used to pay for
Internet
access.
Yes, most of the communities I work with will use cash instead of
plastic.
I just got curious because if that is the case, how can you extend the
voucher just by the admin interface? The user will go physically to the
admin and pay him? I was thinking more of the case where the admin
might
not be available, and it will be faster for the user to get a new
voucher
from a local shop. I think it's very interesting to understand the
different scenarios of community networks.
A community currency would be awesome, and I wonder how can the local
network be a facilitator for it - blockchains running on routers?
--
bruno(a)pobox.com ▀─█▄██▄▀▄
http://brunovianna.net ─█▄██▄▀█▀█▄
skype: randomico▀─█▄██▄▀█▀█▄▌██─█▌█▌
5 Aug
5 Aug
9:24 p.m.
Any updates on this?
On 06/03/2017 05:58 AM, Nicolas Pace wrote:
Hi guys,
Thank you for your input.
For this project we are following an emergent design.
The idea is to have the bare minimum implemented for communities to
install and uninstall, enable and disable... So we can work together
through experimentation to find out the most valuable features and make
them added earlier.
We are focusing on some community networks... If your community wants to
participate on the design process, please right to me in private and
tell me about the community. That will allow us to prioritize.
Bruno , great that you want to contribute by coding... Let's talk in
private, shall we? So we can organize ourselves,
On June 1, 2017 5:49:03 PM GMT+03:00, bruno vianna <bruno(a)pobox.com> wrote:
3) Codes expire and get recycled, yes?
I think the codes should be long enough so that we keep
creating them
and never have to recycle.
Why? For programming reasons? For ease of use in a particular case?
With 5 characters, that's probably enough (11,881,376), and with
7 definitely enough (8,031,810,176) to never repeat on that network.
Would it save processor energy on the router? Or maybe it would
fill up memory on the router?
I think it would be easier if you don't have to keep track of
expired vouchers, but I guess it's question for the coders.
7) When a voucher expires, keep the code reserved in
the system for
10% of the time it was valid, in case the person wants
to renew the
voucher. Examples:
-- A 1 hour voucher of a library/ciber visitor expires,
and they
have a 6-minute grace period to request another hour on
their
voucher. The admin interface makes extending the
voucher easy.
-- A 1 month voucher has a 3-day grace period. The
device doesn't
have access once the voucher expires, but renewing is
easy: the
admin doesn't have to create a new voucher, and the
person doesn't
have to enter a new code.
Are you thinking of an online payment system to get the
vouchers? Then
perhaps the access to the merchant page could be always open
(filter by
domain). Or the merchant page could be in the captive
portal, which is
always accessible.
Money in Caimito is all cash, with an occasional check, and no
cards or online payment so far. I can imagine some tourists
paying by card or some online system if it were available. Some
(maybe most) of the people here don't even have bank accounts
(beyond the Caimito community bank). I can imagine a community
currency being created and used to pay for Internet access.
Yes, most of the communities I work with will use cash instead of
plastic. I just got curious because if that is the case, how can you
extend the voucher just by the admin interface? The user will go
physically to the admin and pay him? I was thinking more of the case
where the admin might not be available, and it will be faster for
the user to get a new voucher from a local shop. I think it's very
interesting to understand the different scenarios of community
networks.
A community currency would be awesome, and I wonder how can the
local network be a facilitator for it - blockchains running on routers?
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
9:29 p.m.
On Sat, 2017-08-05 at 16:24 -0500, Patricio Gibbs wrote:
Any updates on this?
No updates, sorry... no time yet to get here.
If there is any developer that wants to get on this, I can share with
him the aproach we had... but for me it is difficult now... will get on
this later this year.
On 06/03/2017 05:58 AM, Nicolas Pace wrote:
Hi guys,
Thank you for your input.
For this project we are following an emergent design.
The idea is to have the bare minimum implemented for communities
to
install and uninstall, enable and disable... So we can work
together
through experimentation to find out the most valuable features and
make
them added earlier.
We are focusing on some community networks... If your community
wants to
participate on the design process, please right to me in private
and
tell me about the community. That will allow us to prioritize.
Bruno , great that you want to contribute by coding... Let's talk
in
private, shall we? So we can organize ourselves,
On June 1, 2017 5:49:03 PM GMT+03:00, bruno vianna <bruno(a)pobox.com
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users wrote:
3) Codes expire and get recycled, yes?
I think the codes should be long enough so that we keep
creating them
and never have to recycle.
Why? For programming reasons? For ease of use in a
particular case?
With 5 characters, that's probably enough (11,881,376), and
with
7 definitely enough (8,031,810,176) to never repeat on that
network.
Would it save processor energy on the router? Or maybe it
would
fill up memory on the router?
I think it would be easier if you don't have to keep track of
expired vouchers, but I guess it's question for the coders.
7) When a voucher expires, keep the code reserved
in
the system for
10% of the time it was valid, in case the person
wants
to renew the
voucher. Examples:
-- A 1 hour voucher of a library/ciber visitor
expires,
and they
have a 6-minute grace period to request another
hour on
their
voucher. The admin interface makes extending the
voucher easy.
-- A 1 month voucher has a 3-day grace period. The
device doesn't
have access once the voucher expires, but renewing
is
easy: the
admin doesn't have to create a new voucher, and
the
person doesn't
have to enter a new code.
Are you thinking of an online payment system to get the
vouchers? Then
perhaps the access to the merchant page could be always
open
(filter by
domain). Or the merchant page could be in the captive
portal, which is
always accessible.
Money in Caimito is all cash, with an occasional check, and
no
cards or online payment so far. I can imagine some tourists
paying by card or some online system if it were available.
Some
(maybe most) of the people here don't even have bank
accounts
(beyond the Caimito community bank). I can imagine a
community
currency being created and used to pay for Internet access.
Yes, most of the communities I work with will use cash instead
of
plastic. I just got curious because if that is the case, how
can you
extend the voucher just by the admin interface? The user will
go
physically to the admin and pay him? I was thinking more of the
case
where the admin might not be available, and it will be faster
for
the user to get a new voucher from a local shop. I think it's
very
interesting to understand the different scenarios of community
networks.
A community currency would be awesome, and I wonder how can the
local network be a facilitator for it - blockchains running on
routers?
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
6 Aug
6 Aug
2:38 a.m.
This seemed like an interesting and productive conversation.
Nicholas - Just wondering why you took both the dev and the feature
specification 'offline' out of this thread, and now the conversation seems
to be blocked on you needing to do something without it being clear what
that is.
Why not take feature specification to a public space like a wiki page or
something so that people can continue to collaborate and input on it, and
see status, next steps, etc. so it's not blocked by any one person.
Is there any process like this for tracking planed features / roadmap for
LiMe?
James
On Sun, Aug 6, 2017 at 12:29 AM, Nicolas Pace <nico(a)libre.ws> wrote:
On Sat, 2017-08-05 at 16:24 -0500, Patricio Gibbs
wrote:
--
-- lewis.james(a)gmail.com
Any updates on this?
No updates, sorry... no time yet to get here.
If there is any developer that wants to get on this, I can share with
him the aproach we had... but for me it is difficult now... will get on
this later this year.
On 06/03/2017 05:58 AM, Nicolas Pace wrote:
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
Hi guys,
Thank you for your input.
For this project we are following an emergent design.
The idea is to have the bare minimum implemented for communities
to
install and uninstall, enable and disable... So we can work
together
through experimentation to find out the most valuable features and
make
them added earlier.
We are focusing on some community networks... If your community
wants to
participate on the design process, please right to me in private
and
tell me about the community. That will allow us to prioritize.
Bruno , great that you want to contribute by coding... Let's talk
in
private, shall we? So we can organize ourselves,
On June 1, 2017 5:49:03 PM GMT+03:00, bruno vianna <bruno(a)pobox.com
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users wrote:
3) Codes expire and get recycled, yes?
I think the codes should be long enough so that we keep
creating them
and never have to recycle.
Why? For programming reasons? For ease of use in a
particular case?
With 5 characters, that's probably enough (11,881,376), and
with
7 definitely enough (8,031,810,176) to never repeat on that
network.
Would it save processor energy on the router? Or maybe it
would
fill up memory on the router?
I think it would be easier if you don't have to keep track of
expired vouchers, but I guess it's question for the coders.
7) When a voucher expires, keep the code reserved
in
the system for
10% of the time it was valid, in case the person
wants
to renew the
voucher. Examples:
-- A 1 hour voucher of a library/ciber visitor
expires,
and they
have a 6-minute grace period to request another
hour on
their
voucher. The admin interface makes extending the
voucher easy.
-- A 1 month voucher has a 3-day grace period. The
device doesn't
have access once the voucher expires, but renewing
is
easy: the
admin doesn't have to create a new voucher, and
the
person doesn't
have to enter a new code.
Are you thinking of an online payment system to get the
vouchers? Then
perhaps the access to the merchant page could be always
open
(filter by
domain). Or the merchant page could be in the captive
portal, which is
always accessible.
Money in Caimito is all cash, with an occasional check, and
no
cards or online payment so far. I can imagine some tourists
paying by card or some online system if it were available.
Some
(maybe most) of the people here don't even have bank
accounts
(beyond the Caimito community bank). I can imagine a
community
currency being created and used to pay for Internet access.
Yes, most of the communities I work with will use cash instead
of
plastic. I just got curious because if that is the case, how
can you
extend the voucher just by the admin interface? The user will
go
physically to the admin and pay him? I was thinking more of the
case
where the admin might not be available, and it will be faster
for
the user to get a new voucher from a local shop. I think it's
very
interesting to understand the different scenarios of community
networks.
A community currency would be awesome, and I wonder how can the
local network be a facilitator for it - blockchains running on
routers?
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
11:01 a.m.
On Sun, 2017-08-06 at 05:38 +0300, James Lewis wrote:
This seemed like an interesting and productive
conversation.
Nicholas - Just wondering why you took both the dev and the feature
specification 'offline' out of this thread, and now the conversation
seems to be blocked on you needing to do something without it being
clear what that is.
The things that I planned to be done are here:
https://github.com/libremesh/pitbull/issues
Basically I got to work on PitBull cause Quintana Commoners needed it,
but now I don't have time to follow it up for the moment.
Not an offline-online thing... the process is just stalled on my hands.
Why not take feature specification to a public space
like a wiki page
or something so that people can continue to collaborate and input on
it, and see status, next steps, etc. so it's not blocked by any one
person.
It is there... the thing is that there is noone to code.
I understand that this feature is relevant for many communities, but we
need more coders to get involved so we don't have just feature requests
but also features implemented.
Regretably, I'm not being able to put time on this for now... so if
someone else is interested, more than welcomed to get on it.
On time I will be able to get back on this.
Is there any process like this for tracking planed
features / roadmap
for LiMe?
Will reply to this in another thread :)
11:05 a.m.
New subject: [lime-users] Community Building and Governance ERA Re: vouchers / vale.sh replacement
On Sun, 2017-08-06 at 05:38 +0300, James Lewis wrote:
Is there any process like this for tracking planed
features / roadmap
for LiMe?
Not for now I guess... from my understanding most things are being
discussed over the mailing list...
This is very interesting... as more people come together and can start
collaborating, I think it would be much easier to have time allocated
in new features.
My guess is that we just need more hands involved on coding :)
For what I see the core team has had close to no time to work on new
stuff.. just stabilizing the core, and we are still on that task, so it
is very difficult to allocate time on what comes forward.
The good thing about starting to be more, is that we can start
distributing labor, and talking about needs of the communities.
On the last week we have been talking about:
* a space for knowledge sharing apart of the website and the mailing
list, like a wiki
* a space where features can be tracked/planned
Community members are working on:
* a translation platform for the whole project
I would say... we can discuss on this space what do we need, how we can
solve it, and who can get it done and maintain it.
What do you think about this?
Regareds,
7 Aug
7 Aug
8:23 a.m.
New subject: [lime-users] Community Building and Governance ERA Re: vouchers / vale.sh replacement
I think a place like discourse with mailing list mode enabled would be the best of both
worlds in terms of community topics and such.
https://try.discourse.org/
It allows everyone to view topics online or via email or both [only via email working
exactly like a traditional mailman ml], in a perfectly seamless and synced way.
I have a self hosted version for 1€ a month for my project and I could create one for LiMe
by tonight at no cost for anyone [I think I can handle another € a month ;]
As for issue tracking and so on, how are we using GitHub right now? Could we actually make
it our base for these things?
As for milestones and voting how about democracyos / loomio / … ?
Nk
On 6 August 2017 at 13:05:39, Nicolas Pace (nico(a)libre.ws) wrote:
On Sun, 2017-08-06 at 05:38 +0300, James Lewis wrote:
Is there any process like this for tracking planed
features / roadmap
for LiMe?
Not for now I guess... from my understanding most things are being
discussed over the mailing list...
This is very interesting... as more people come together and can start
collaborating, I think it would be much easier to have time allocated
in new features.
My guess is that we just need more hands involved on coding :)
For what I see the core team has had close to no time to work on new
stuff.. just stabilizing the core, and we are still on that task, so it
is very difficult to allocate time on what comes forward.
The good thing about starting to be more, is that we can start
distributing labor, and talking about needs of the communities.
On the last week we have been talking about:
* a space for knowledge sharing apart of the website and the mailing
list, like a wiki
* a space where features can be tracked/planned
Community members are working on:
* a translation platform for the whole project
I would say... we can discuss on this space what do we need, how we can
solve it, and who can get it done and maintain it.
What do you think about this?
Regareds,_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
9:15 a.m.
New subject: [lime-users] Community Building and Governance ERA Re: vouchers / vale.sh replacement
On Mon, 2017-08-07 at 10:23 +0200, Nk via lime-users wrote:
I think a place like discourse with mailing list mode
enabled would
be the best of both worlds in terms of community topics and such.
I feel that talking about concrete tools at this point would get us
into a conversation of which tools are best, instead of being able to
recoginse what we need and, based on what we have, we can see what new
services we deploy.
Makes sense?
On 6 August 2017 at 13:05:39, Nicolas Pace
(nico(a)libre.ws) wrote:
On Sun, 2017-08-06 at 05:38 +0300, James Lewis
wrote:
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users Is there any process like this for tracking
planed features /
roadmap
for LiMe?
Not for now I guess... from my understanding most things are being
discussed over the mailing list...
This is very interesting... as more people come together and can
start
collaborating, I think it would be much easier to have time
allocated
in new features.
My guess is that we just need more hands involved on coding :)
For what I see the core team has had close to no time to work on
new
stuff.. just stabilizing the core, and we are still on that task,
so it
is very difficult to allocate time on what comes forward.
The good thing about starting to be more, is that we can start
distributing labor, and talking about needs of the communities.
On the last week we have been talking about:
* a space for knowledge sharing apart of the website and the
mailing
list, like a wiki
* a space where features can be tracked/planned
Community members are working on:
* a translation platform for the whole project
I would say... we can discuss on this space what do we need, how we
can
solve it, and who can get it done and maintain it.
What do you think about this?
Regareds,_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
9:28 a.m.
New subject: [lime-users] Community Building and Governance ERA Re: vouchers / vale.sh replacement
I thought the needs were already recognised, or at least, let’s say I agree in thinking
they exist ;]
But really, I think tracking issues is an absolute must.
Nk
On 7 August 2017 at 11:15:41, Nicolas Pace (nico(a)libre.ws) wrote:
On Mon, 2017-08-07 at 10:23 +0200, Nk via lime-users wrote:
I think a place like discourse with mailing list mode
enabled would
be the best of both worlds in terms of community topics and such.
I feel that talking about concrete tools at this point would get us
into a conversation of which tools are best, instead of being able to
recoginse what we need and, based on what we have, we can see what new
services we deploy.
Makes sense?
On 6 August 2017 at 13:05:39, Nicolas Pace
(nico(a)libre.ws) wrote:
On Sun, 2017-08-06 at 05:38 +0300, James Lewis
wrote:
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users Is there any process like this for tracking
planed features /
roadmap
for LiMe?
Not for now I guess... from my understanding most things are being
discussed over the mailing list...
This is very interesting... as more people come together and can
start
collaborating, I think it would be much easier to have time
allocated
in new features.
My guess is that we just need more hands involved on coding :)
For what I see the core team has had close to no time to work on
new
stuff.. just stabilizing the core, and we are still on that task,
so it
is very difficult to allocate time on what comes forward.
The good thing about starting to be more, is that we can start
distributing labor, and talking about needs of the communities.
On the last week we have been talking about:
* a space for knowledge sharing apart of the website and the
mailing
list, like a wiki
* a space where features can be tracked/planned
Community members are working on:
* a translation platform for the whole project
I would say... we can discuss on this space what do we need, how we
can
solve it, and who can get it done and maintain it.
What do you think about this?
Regareds,_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
9 Aug
9 Aug
3:11 p.m.
El 5 de agosto de 2017 16:29:29 GMT-05:00, Nicolas Pace <nico(a)libre.ws> escribió:
On Sat, 2017-08-05 at 16:24 -0500, Patricio Gibbs
wrote:
I will look for coders, and in order to do that I need a spec of the necessary skills.
I'm guessing that a request for coders needs to say what programming languages or
frameworks are being used; who the contact person is that will explain the coding
practices of the project; where the code is. Anything else I need to specify in the
request for coders?
Any updates on this?
No updates, sorry... no time yet to get here.
If there is any developer that wants to get on this, I can share with
him the aproach we had... but for me it is difficult now... will get on
this later this year.
> On 06/03/2017 05:58 AM, Nicolas Pace wrote:
> > Hi guys,
> > Thank you for your input.
> > For this project we are following an emergent design.
> > The idea is to have the bare minimum implemented for communities
> > to
> > install and uninstall, enable and disable... So we can work
> > together
> > through experimentation to find out the most valuable features and
> > make
> > them added earlier.
> > We are focusing on some community networks... If your community
> > wants to
> > participate on the design process, please right to me in private
> > and
> > tell me about the community. That will allow us to prioritize.
> >
> > Bruno , great that you want to contribute by coding... Let's talk
> > in
> > private, shall we? So we can organize ourselves,
> >
> > On June 1, 2017 5:49:03 PM GMT+03:00, bruno vianna <bruno(a)pobox.com
> > > wrote:
> >
> >
> > 3) Codes expire and get recycled, yes?
> >
> >
> > I think the codes should be long enough so that we keep
> > creating them
> > and never have to recycle.
> >
> >
> > Why? For programming reasons? For ease of use in a
> > particular case?
> >
> > With 5 characters, that's probably enough (11,881,376), and
> > with
> > 7 definitely enough (8,031,810,176) to never repeat on that
> > network.
> >
> > Would it save processor energy on the router? Or maybe it
> > would
> > fill up memory on the router?
> >
> >
> > I think it would be easier if you don't have to keep track of
> > expired vouchers, but I guess it's question for the coders.
> >
> >
> >
> >
> >
> > 7) When a voucher expires, keep the code reserved
> > in
> > the system for
> > 10% of the time it was valid, in case the person
> > wants
> > to renew the
> > voucher. Examples:
> > -- A 1 hour voucher of a library/ciber visitor
> > expires,
> > and they
> > have a 6-minute grace period to request another
> > hour on
> > their
> > voucher. The admin interface makes extending the
> > voucher easy.
> > -- A 1 month voucher has a 3-day grace period. The
> > device doesn't
> > have access once the voucher expires, but renewing
> > is
> > easy: the
> > admin doesn't have to create a new voucher, and
> > the
> > person doesn't
> > have to enter a new code.
> >
> >
> > Are you thinking of an online payment system to get the
> > vouchers? Then
> > perhaps the access to the merchant page could be always
> > open
> > (filter by
> > domain). Or the merchant page could be in the captive
> > portal, which is
> > always accessible.
> >
> > Money in Caimito is all cash, with an occasional check, and
> > no
> > cards or online payment so far. I can imagine some tourists
> > paying by card or some online system if it were available.
> > Some
> > (maybe most) of the people here don't even have bank
> > accounts
> > (beyond the Caimito community bank). I can imagine a
> > community
> > currency being created and used to pay for Internet access.
> >
> >
> >
> > Yes, most of the communities I work with will use cash instead
> > of
> > plastic. I just got curious because if that is the case, how
> > can you
> > extend the voucher just by the admin interface? The user will
> > go
> > physically to the admin and pay him? I was thinking more of the
> > case
> > where the admin might not be available, and it will be faster
> > for
> > the user to get a new voucher from a local shop. I think it's
> > very
> > interesting to understand the different scenarios of community
> > networks.
> >
> > A community currency would be awesome, and I wonder how can the
> > local network be a facilitator for it - blockchains running on
> > routers?
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > lime-users mailing list
> > lime-users(a)lists.libremesh.org
> > https://lists.libremesh.org/mailman/listinfo/lime-users
> >
>
> _______________________________________________
> lime-users mailing list
> lime-users(a)lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-users
12 Aug
12 Aug
3:53 p.m.
On Wed, 2017-08-09 at 10:11 -0500, Patrick Patricio Gibbs wrote:
El 5 de agosto de 2017 16:29:29 GMT-05:00, Nicolas Pace <nico(a)libre.w
s> escribió:
LUA and IPTables understanding.
Also, knowing about OpenWRT doesn't hurt.
On Sat, 2017-08-05 at 16:24 -0500, Patricio Gibbs
wrote:
I will look for coders, and in order to do that I need a spec of the
necessary skills. Any updates on this?
No updates, sorry... no time yet to get here.
If there is any developer that wants to get on this, I can share
with
him the aproach we had... but for me it is difficult now... will
get on
this later this year.
I'm guessing that a request for coders needs to
say what programming
languages or frameworks are being used; who the contact person is
that will explain the coding practices of the project; where the code
is. Anything else I need to specify in the request for coders?
https://github.com/libremesh/pitbull
Mmm... I would expect from someone from the community to come
forward...
I will try to send a more detailed email about this later.
regards,
> On 06/03/2017 05:58 AM, Nicolas Pace wrote:
> > Hi guys,
> > Thank you for your input.
> > For this project we are following an emergent design.
> > The idea is to have the bare minimum implemented for
> > communities
> > to
> > install and uninstall, enable and disable... So we can work
> > together
> > through experimentation to find out the most valuable features
> > and
> > make
> > them added earlier.
> > We are focusing on some community networks... If your community
> > wants to
> > participate on the design process, please right to me in
> > private
> > and
> > tell me about the community. That will allow us to prioritize.
> >
> > Bruno , great that you want to contribute by coding... Let's
> > talk
> > in
> > private, shall we? So we can organize ourselves,
> >
> > On June 1, 2017 5:49:03 PM GMT+03:00, bruno vianna <bruno@pobox
> > .com
> > > wrote:
> >
> >
> > 3) Codes expire and get recycled, yes?
> >
> >
> > I think the codes should be long enough so that we
> > keep
> > creating them
> > and never have to recycle.
> >
> >
> > Why? For programming reasons? For ease of use in a
> > particular case?
> >
> > With 5 characters, that's probably enough (11,881,376),
> > and
> > with
> > 7 definitely enough (8,031,810,176) to never repeat on
> > that
> > network.
> >
> > Would it save processor energy on the router? Or maybe
> > it
> > would
> > fill up memory on the router?
> >
> >
> > I think it would be easier if you don't have to keep track
> > of
> > expired vouchers, but I guess it's question for the coders.
> >
> >
> >
> >
> >
> > 7) When a voucher expires, keep the code
> > reserved
> > in
> > the system for
> > 10% of the time it was valid, in case the
> > person
> > wants
> > to renew the
> > voucher. Examples:
> > -- A 1 hour voucher of a library/ciber visitor
> > expires,
> > and they
> > have a 6-minute grace period to request
> > another
> > hour on
> > their
> > voucher. The admin interface makes extending
> > the
> > voucher easy.
> > -- A 1 month voucher has a 3-day grace period.
> > The
> > device doesn't
> > have access once the voucher expires, but
> > renewing
> > is
> > easy: the
> > admin doesn't have to create a new voucher,
> > and
> > the
> > person doesn't
> > have to enter a new code.
> >
> >
> > Are you thinking of an online payment system to get
> > the
> > vouchers? Then
> > perhaps the access to the merchant page could be
> > always
> > open
> > (filter by
> > domain). Or the merchant page could be in the
> > captive
> > portal, which is
> > always accessible.
> >
> > Money in Caimito is all cash, with an occasional check,
> > and
> > no
> > cards or online payment so far. I can imagine some
> > tourists
> > paying by card or some online system if it were
> > available.
> > Some
> > (maybe most) of the people here don't even have bank
> > accounts
> > (beyond the Caimito community bank). I can imagine a
> > community
> > currency being created and used to pay for Internet
> > access.
> >
> >
> >
> > Yes, most of the communities I work with will use cash
> > instead
> > of
> > plastic. I just got curious because if that is the case,
> > how
> > can you
> > extend the voucher just by the admin interface? The user
> > will
> > go
> > physically to the admin and pay him? I was thinking more of
> > the
> > case
> > where the admin might not be available, and it will be
> > faster
> > for
> > the user to get a new voucher from a local shop. I think
> > it's
> > very
> > interesting to understand the different scenarios of
> > community
> > networks.
> >
> > A community currency would be awesome, and I wonder how can
> > the
> > local network be a facilitator for it - blockchains
> > running on
> > routers?
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > lime-users mailing list
> > lime-users(a)lists.libremesh.org
> > https://lists.libremesh.org/mailman/listinfo/lime-users
> >
>
> _______________________________________________
> lime-users mailing list
> lime-users(a)lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-users
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
2442
days inactive
2516
days old
lime-users@lists.libremesh.org
14 comments
6 participants
participants (6)
-
bruno vianna -
James Lewis -
Nicolas Pace -
Nk -
Patricio Gibbs -
Patrick Patricio Gibbs