I've set up a $6 a month VPS (vpscheap.net) and configured mail for our domains peoplesopen.net and sudoroom.org (and all variations).

Hi! meshthepla.net) Ehm? Freifunk is already doing this and quite successfully. I would suggest not to try to duplicate efforts: https://github.com/freifunk/api.freifunk.net https://github.com/freifunk/api.freifunk.net/blob/master/directory/director…

Hi! Yes: http://freifunk.net/ I think they are doing great job and if something is not yet done, it is probably better to contribute.

http://blog.freifunk.net/2013/neue-version-des-freifunkapijsongenerator-rel… I don't think they want to be Freifunk specific. But yes, you could pull through same API and have a different site, if you think there would be some value to that.

On Tue, Sep 24, 2013 at 12:20 AM, Marc Juul <juul(a)labitat.dk> wrote: our I must have been pretty tired when I wrote this. I of course meant sudomesh.org I'm also not sure that this has been officially announced on the mailing list, but our final naming decisions are in. The network is: Peoples Open Network peoplesopen.net The SSID of the wifi/mesh is: peoplesopen.net The organization is: sudomesh.org and then we are thinking about using meshtheplanet.net (and meshthepla.net) as a campaign to get more people involved or a map of all community networks (like hackerspaces.org) We decided to change the decision from last week and not use the name peopleswifi.org as the SSID so as not to have two different names for the network.

As far as global directories, I don't see any reason for freifunk to be the only front end for all this open data - in part because "freifunk" is a much better name for german speakers than for everyone else. As long as we are dealing with open data and open source, it shouldn't be a problem for motivated folks to throw up their own translated/localized version, experiment with visualizations, etc. if they want to

--mark B. On Sep 24, 2013 6:47 PM, "Mitar" <mitar(a)tnode.com> wrote:

Marc Juul <juul(a)labitat.dk> wrote: Would you be willing to work with the Free Network Foundation and our guifi.us effort for the mapping? Also look at guifi.net (they are working closely with global mesh networks to map everything). -- Charles Wyble (818) 280-7059 charles(a)knownelement.com CTO Free Network Foundation (thefnf.org) _______________________________________________ mesh mailing list mesh(a)lists.sudoroom.org http://lists.sudoroom.org/listinfo/mesh

Hi! So, maybe you should talk with people behind the freifunk.net site and see what is their vision is? Probably they are just around the corner. :-) As I said, there could be two domain names pointing to the same page, meshthepla.net having different theme and different (English) locale. Mitar agnostic after as for nice https://github.com/freifunk/api.freifunk.net/blob/master/directory/director… https://github.com/freifunk/api.freifunk.net/blob/master/specs/0.1.json eager this because I https://en.wikipedia.org/wiki/List_of_wireless_community_networks_by_region -- http://mitar.tnode.com/ https://twitter.com/mitar_m

Charles, Can you link to a guifi.net page that demonstrates this global map? Something in English, preferably. I'd love to know more about this project and its roadmap. On Sep 25, 2013 3:55 AM, <charles(a)thefnf.org> wrote: for name for > >the > >network. > > Would you be willing to work with the Free Network Foundation and our > guifi.us effort for the mapping? > > Also look at guifi.net (they are working closely with global mesh > networks to map everything). > -- > Charles Wyble > (818) 280-7059 charles(a)knownelement.com > CTO Free Network Foundation (thefnf.org) > > _______________________________________________ > mesh mailing list > mesh(a)lists.sudoroom.org > http://lists.sudoroom.org/listinfo/mesh >

On a general note I'm highly skeptical of any database built on top of JSON.

My hope is for an API to be built for this dataset such that individual mesh networks are not forced into using this one size fits all biz.

Traditionally JSON is the way you'd interface with a database through a web app and not the database itself. The real problem is that JSON is a *data structure* and not a *database*. All the awesome tools one might want to use for sorting data sets are written for relational databases and not JSON objects. Using anything but a relational database doesn't make much sense to me if we are to prepare for the beautiful future of 100k+ node meshes. Writing a relational database to JSON object script is trivial, I'd put money on multiple libraries existing in all popular languages for just this. Not all mesh networks are created equal, for example some route on layer 2 while others route on layer 3. Should every entry in the JSON "database" contain both a MAC and IP address because of this? There are thousands of other variations which would each require their own JSON attribute even though 95% of the nodes may leave it undefined. Instead of defining a shared database efforts should be focused on defining a shared data structure. This data structure can be (and IMO should be) JSON and would contain a list of common attributes, not an all-inclusive list of attributes. Each organization can define their own database and need only write a script to export common attributes into the JSON shared data structure. -- rhodey On 09/25/2013 02:57 PM, Mitar wrote: _______________________________________________ mesh mailing list mesh(a)lists.sudoroom.org http://lists.sudoroom.org/listinfo/mesh

freifunk's api is re: a directory of networks not nodes. The json would basically be a url we maintain about our network that provides metadata such as name of our network, number of nodes, access policy, URLs for more info, etc. The json just represents our entry in a directory (or multiple directories) of mesh networks. I'm pretty sure no one is suggesting using json as a database, that doesn't make any sense... --mark Traditionally JSON is the way you'd interface with a database through a web app and not the database itself. The real problem is that JSON is a *data structure* and not a *database*. All the awesome tools one might want to use for sorting data sets are written for relational databases and not JSON objects. Using anything but a relational database doesn't make much sense to me if we are to prepare for the beautiful future of 100k+ node meshes. Writing a relational database to JSON object script is trivial, I'd put money on multiple libraries existing in all popular languages for just this. Not all mesh networks are created equal, for example some route on layer 2 while others route on layer 3. Should every entry in the JSON "database" contain both a MAC and IP address because of this? There are thousands of other variations which would each require their own JSON attribute even though 95% of the nodes may leave it undefined. Instead of defining a shared database efforts should be focused on defining a shared data structure. This data structure can be (and IMO should be) JSON and would contain a list of common attributes, not an all-inclusive list of attributes. Each organization can define their own database and need only write a script to export common attributes into the JSON shared data structure. -- rhodey On 09/25/2013 02:57 PM, Mitar wrote: _______________________________________________ mesh mailing list mesh(a)lists.sudoroom.org <mailto:mesh@lists.sudoroom.org> http://lists.sudoroom.org/listinfo/mesh