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@libre.ws> wrote:
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@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@lists.libremesh.org
> > https://lists.libremesh.org/mailman/listinfo/lime-users
> >
>
> _______________________________________________
> lime-users mailing list
> lime-users@lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-users

_______________________________________________
lime-users mailing list
lime-users@lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users



--