From 690277cb014a31582a98905583ee5f28e83a4ee5 Mon Sep 17 00:00:00 2001 From: Chris Ritzo Date: Mon, 24 Feb 2014 16:36:03 -0500 Subject: [PATCH] updated blog front page template to provide the 10 most recent post teasers, updated the front page teaser view as well. Both teaser views show the blog post title, date, author,some of the text and the image defined in each post's front matter variable teaser_image: added pikwi include code. --- test.commotion/_config.yml | 3 + .../_includes/blog-front-content.html | 11 + test.commotion/_includes/footer.html | 2 +- test.commotion/_includes/piwik-code | 15 ++ test.commotion/_layouts/blog-front.html | 2 +- test.commotion/_layouts/front.html | 15 +- ...rticipates-dc-internet-freedom-hack-day.md | 1 + test.commotion/_site/about/faq/index.html | 63 ++++-- .../_site/about/guiding-principles/index.html | 51 +++-- test.commotion/_site/about/index.html | 41 ++-- .../_site/about/license-privacy/index.html | 33 ++- test.commotion/_site/about/press/index.html | 47 ++-- .../_site/about/where-its-used/index.html | 63 ++++-- test.commotion/_site/access-denied/index.html | 27 ++- .../index.html" | 64 ++++-- .../index.html | 68 +++--- .../index.html | 90 ++++---- .../index.html | 52 +++-- .../2012/08/22/exploring-meshaging/index.html | 48 ++-- .../08/23/meshtether-test-release/index.html | 48 ++-- .../_site/blog/2012/09/19/making/index.html | 48 ++-- .../10/08/diving-deeper-meshaging/index.html | 56 +++-- .../01/updating-commotion-package/index.html | 130 ++++++----- .../index.html | 52 +++-- .../2012/11/14/cost-mesh-networks/index.html | 56 +++-- .../index.html | 74 ++++--- .../index.html | 68 +++--- .../index.html | 68 +++--- .../index.html | 116 +++++----- .../index.html | 78 ++++--- .../index.html | 44 ++-- .../index.html | 56 +++-- .../index.html | 64 ++++-- .../index.html | 108 +++++---- .../index.html | 60 +++-- .../index.html | 112 ++++++---- .../index.html | 52 +++-- .../index.html | 60 +++-- .../index.html | 62 ++++-- .../index.html | 76 ++++--- .../19/commotion-dr2-release-notes/index.html | 112 ++++++---- .../index.html | 138 +++++++----- .../index.html | 68 +++--- .../building-popup-mesh-networks/index.html | 102 +++++---- .../index.html | 56 +++-- .../index.html | 112 ++++++---- .../commotion-r1-breaking-changes/index.html | 60 +++-- .../index.html | 56 +++-- test.commotion/_site/blog/index.html | 208 +++++++++++++++++- test.commotion/_site/chat/index.html | 27 ++- .../_site/content/about-commotion/index.html | 29 ++- .../content/commotion-10-released/index.html | 25 ++- .../_site/content/get-involved/index.html | 35 ++- .../_site/content/get-started/index.html | 35 ++- .../questions-about-commotion/index.html | 25 ++- test.commotion/_site/css/commotion.css | 91 +++++++- .../hig/design-principles/index.html | 65 +++--- .../_site/developer/hig/downloads/index.html | 41 ++-- .../developer/hig/introduction/index.html | 69 +++--- .../developer/hig/key-concepts/index.html | 85 ++++--- .../developer/hig/key-processes/index.html | 85 ++++--- .../_site/developer/hig/style/index.html | 59 +++-- .../hig/updating-guidelines/index.html | 41 ++-- .../_site/developer/resources/index.html | 41 ++-- .../grounding-lightning-protection/index.html | 35 ++- .../docs/build/roof-mount-guide/index.html | 35 ++- .../index.html | 109 +++++---- .../docs/cck/building-mounting/index.html | 31 ++- .../learn-about-rooftop-mounts/index.html | 109 +++++---- .../learn-rooftop-basics/index.html | 109 +++++---- .../prep-install-rooftop-nodes/index.html | 109 +++++---- test.commotion/_site/docs/cck/index.html | 77 ++++--- .../common-configuration/index.html | 111 ++++++---- .../configure-commotion/index.html | 111 ++++++---- .../cck/installing-configuring/index.html | 31 ++- .../install-and-recover-tftp/index.html | 111 ++++++---- .../install-ubiquiti-router/index.html | 111 ++++++---- .../index.html | 111 ++++++---- .../_site/docs/cck/networking/index.html | 31 ++- .../cck/networking/intro-to-mesh/index.html | 105 +++++---- .../learn-networking-basics/index.html | 105 +++++---- .../index.html | 95 ++++---- .../index.html | 115 +++++----- .../get-word-out-flyer-design/index.html | 115 +++++----- .../identify-neighborhood-skills/index.html | 115 +++++----- .../_site/docs/cck/planning/index.html | 31 ++- .../inventory-the-neighborhood/index.html | 115 +++++----- .../planning/survey-your-neighbors/index.html | 115 +++++----- .../planning/wireless-challenges/index.html | 115 +++++----- .../_site/docs/get-involved/index.html | 53 +++-- .../_site/docs/get-started/index.html | 61 +++-- test.commotion/_site/docs/hig/index.html | 25 ++- test.commotion/_site/docs/index.html | 61 +++-- .../_site/docs/localization/index.html | 61 +++-- .../_site/docs/supported-devices/index.html | 61 +++-- .../download-commotion-client/index.html | 27 ++- .../_site/download/android/index.html | 64 ++++-- .../_site/download/computers/index.html | 59 +++-- test.commotion/_site/download/index.html | 35 ++- .../_site/download/openbts/index.html | 65 ++++-- .../download/openwrt/ubiquiti/index.html | 35 ++- .../_site/download/routers/index.html | 88 +++++--- .../download/verify-signatures/index.html | 35 ++- test.commotion/_site/es/index.html | 113 +++------- test.commotion/_site/help/connect/index.html | 25 ++- .../_site/help/questions/index.html | 25 ++- test.commotion/_site/index.html | 146 +++++------- test.commotion/_site/jobs/index.html | 43 ++-- test.commotion/_site/non-front.html | 35 ++- test.commotion/_site/osmobts/index.html | 27 ++- .../index.html | 35 ++- test.commotion/blog/index.md | 1 - test.commotion/css/commotion.css | 4 +- 113 files changed, 4553 insertions(+), 2737 deletions(-) create mode 100644 test.commotion/_includes/blog-front-content.html create mode 100644 test.commotion/_includes/piwik-code diff --git a/test.commotion/_config.yml b/test.commotion/_config.yml index 8d965ac4..fdd4b988 100644 --- a/test.commotion/_config.yml +++ b/test.commotion/_config.yml @@ -5,6 +5,9 @@ encoding: utf-8 url: "staging.commotionwireless.net" port: 80 +piwik: + base_url: piwik.opentechinstitute.org + site_id: 1 permalink: /blog/:year/:month/:day/:title pagination: 3 diff --git a/test.commotion/_includes/blog-front-content.html b/test.commotion/_includes/blog-front-content.html new file mode 100644 index 00000000..e69e3ecb --- /dev/null +++ b/test.commotion/_includes/blog-front-content.html @@ -0,0 +1,11 @@ +

Recent Blog Posts

+ {% for post in site.posts limit: 10 %} +
+

{{ post.title }}

+ +

{{ post.date | date: "%B %d, %Y" }} {{ post.post_author }}

+

{{ post.content | split:'' | first | strip_html }}

+ Read More +
+
+ {% endfor %} diff --git a/test.commotion/_includes/footer.html b/test.commotion/_includes/footer.html index 34cfaa2b..a1143b7b 100644 --- a/test.commotion/_includes/footer.html +++ b/test.commotion/_includes/footer.html @@ -15,6 +15,6 @@ - +{% include piwik-code %} diff --git a/test.commotion/_includes/piwik-code b/test.commotion/_includes/piwik-code new file mode 100644 index 00000000..f7fd316a --- /dev/null +++ b/test.commotion/_includes/piwik-code @@ -0,0 +1,15 @@ + + + diff --git a/test.commotion/_layouts/blog-front.html b/test.commotion/_layouts/blog-front.html index 16767059..9f617a3f 100644 --- a/test.commotion/_layouts/blog-front.html +++ b/test.commotion/_layouts/blog-front.html @@ -3,7 +3,7 @@ {% include pageheadings.html %} {% include content-area-open.html %} {% include left-twothird-open.html %} -{{ content }} +{% include blog-front-content.html %} {% include left-twothird-close.html %} {% include right-col-start.html %} {% include blog-release-post.html %} diff --git a/test.commotion/_layouts/front.html b/test.commotion/_layouts/front.html index 3207d94d..54b2a1ed 100644 --- a/test.commotion/_layouts/front.html +++ b/test.commotion/_layouts/front.html @@ -8,13 +8,14 @@
-

Recent Blog Posts

- - - - - - +

Recent Blog Posts

+ {% for post in site.posts limit: 3 %} +
+

{{ post.title }}

+

{{ post.date | date: "%B %d, %Y" }} {{ post.post_author }}

+

{{ post.content | split:'' | first | strip_html }}

+
+ {% endfor %}
diff --git a/test.commotion/_posts/2014-01-14-commotion-team-participates-dc-internet-freedom-hack-day.md b/test.commotion/_posts/2014-01-14-commotion-team-participates-dc-internet-freedom-hack-day.md index 651cdbbe..0b47b3d7 100644 --- a/test.commotion/_posts/2014-01-14-commotion-team-participates-dc-internet-freedom-hack-day.md +++ b/test.commotion/_posts/2014-01-14-commotion-team-participates-dc-internet-freedom-hack-day.md @@ -5,6 +5,7 @@ categories: [ui,ux,hack day] created: 2014-01-14 changed: 2014-01-15 post_author: critzo +teaser_image: uihackday-011114.jpeg lang: en --- Commotion card sort activity from the DC Internet Freedom Hack Day, 1/11/2014 diff --git a/test.commotion/_site/about/faq/index.html b/test.commotion/_site/about/faq/index.html index d3dba4dc..b814f8b0 100644 --- a/test.commotion/_site/about/faq/index.html +++ b/test.commotion/_site/about/faq/index.html @@ -1,4 +1,3 @@ - @@ -17,7 +16,7 @@ -
+
@@ -31,6 +30,7 @@
+ @@ -107,6 +107,28 @@

FAQ

+
+ + + + + + + +
+

General

What is Commotion?
@@ -145,28 +167,6 @@

General

What is Commotion?
Commotion is a suite of tools designed to take advantage of any available satellite Internet service, and that connection may be shared with anyone on the network. If no Internet connection is available, network users may still communicate securely and anonymously with each other. Finally, the network is designed to be self-healing, allowing users to join and leave the network as needed.

-
- - - - - - - -
-
@@ -187,6 +187,21 @@

About

+ + + diff --git a/test.commotion/_site/about/guiding-principles/index.html b/test.commotion/_site/about/guiding-principles/index.html index 9f2f5c03..f3a96b72 100644 --- a/test.commotion/_site/about/guiding-principles/index.html +++ b/test.commotion/_site/about/guiding-principles/index.html @@ -1,4 +1,3 @@ - @@ -17,7 +16,7 @@ -
+
@@ -31,6 +30,7 @@
+ @@ -107,22 +107,7 @@

Guiding Principles

-
- -

Commotion Project Guiding Principles

    -
  • The Commotion project is an open source, free software toolkit. The community welcomes all contributions and conversations that help the project grow and improve in accordance with its mission.
    -  
    • -
  • Commotion’s Mission and Goals are guided by the active developers and community stakeholders who contribute to the project community. Active developers of Commotion projects will guide the development of their individual project.
    -  
    • -
  • The Commotion project team encourages communities to customize the software to better meet local needs. We request that all customizations be contributed or communicated back to the Commotion community so that improvements can be reused without undue duplication of effort.
    -  
    • -
  • Work on Commotion should do no harm to existing projects. Projects that implement new code that breaks the existing functionality of other Commotion projects should work with the community of the existing project in order to provide support for the existing functions.
    -  
    • -
  • New members may contribute to existing Commotion projects by collaborating with active developers. Each Commotion subproject will maintain an active version-controlled code repository. Guidelines for contribution will be managed by each project’s active developers, and will be posted on each project’s development page.
    • -
-
- -
+
@@ -142,6 +127,21 @@

About

+
+ +
+ +

Commotion Project Guiding Principles

    +
  • The Commotion project is an open source, free software toolkit. The community welcomes all contributions and conversations that help the project grow and improve in accordance with its mission.
    +  
    • +
  • Commotion’s Mission and Goals are guided by the active developers and community stakeholders who contribute to the project community. Active developers of Commotion projects will guide the development of their individual project.
    +  
    • +
  • The Commotion project team encourages communities to customize the software to better meet local needs. We request that all customizations be contributed or communicated back to the Commotion community so that improvements can be reused without undue duplication of effort.
    +  
    • +
  • Work on Commotion should do no harm to existing projects. Projects that implement new code that breaks the existing functionality of other Commotion projects should work with the community of the existing project in order to provide support for the existing functions.
    +  
    • +
  • New members may contribute to existing Commotion projects by collaborating with active developers. Each Commotion subproject will maintain an active version-controlled code repository. Guidelines for contribution will be managed by each project’s active developers, and will be posted on each project’s development page.
    • +
@@ -164,6 +164,21 @@

About

+ + + diff --git a/test.commotion/_site/about/index.html b/test.commotion/_site/about/index.html index 72a05d89..bc22f76b 100644 --- a/test.commotion/_site/about/index.html +++ b/test.commotion/_site/about/index.html @@ -1,4 +1,3 @@ - @@ -17,7 +16,7 @@ -
+
@@ -31,6 +30,7 @@
+ @@ -107,17 +107,7 @@

About Commotion

-
- -

Commotion is a free, open-source communication tool that uses mobile phones, computers, and other wireless devices to create decentralized mesh networks. Commotion provides a way for you to share your Internet connection with the people around you, but it is not a replacement for your Internet connection. Read more about how Commotion works on our Frequently Asked Questions page.

Mesh Networking Across Devices

Wireless mesh networks allow devices to connect directly to each other without going through a centralized point. Mesh networks are self-healing and can grow organically. They also allow for easy sharing of services over the network, such as Internet and applications.

We aim to:

    -
  • create a simple, easy-to-use communications tool that anyone can set up and use without technical expertise
    • -
  • provide a platform for building community wireless networks and hosting local applications
    • -
  • build a tool for creating infrastructure that is resilient against surveillance and disruption
    • -
  • develop a flexible, open-source software platform that programmers around the globe can continually adapt and build upon
    • -

Want to learn more?

Learn more about where Commotion is being tested. To learn how Commotion works, read our documentation.

Feel free to contact us.

Commotion is led by the Open Technology Institute.

Open Technology Institute logo

-
- -
+
@@ -137,6 +127,16 @@

About

+
+ +
+ +

Commotion is a free, open-source communication tool that uses mobile phones, computers, and other wireless devices to create decentralized mesh networks. Commotion provides a way for you to share your Internet connection with the people around you, but it is not a replacement for your Internet connection. Read more about how Commotion works on our Frequently Asked Questions page.

Mesh Networking Across Devices

Wireless mesh networks allow devices to connect directly to each other without going through a centralized point. Mesh networks are self-healing and can grow organically. They also allow for easy sharing of services over the network, such as Internet and applications.

We aim to:

    +
  • create a simple, easy-to-use communications tool that anyone can set up and use without technical expertise
    • +
  • provide a platform for building community wireless networks and hosting local applications
    • +
  • build a tool for creating infrastructure that is resilient against surveillance and disruption
    • +
  • develop a flexible, open-source software platform that programmers around the globe can continually adapt and build upon
    • +

Want to learn more?

Learn more about where Commotion is being tested. To learn how Commotion works, read our documentation.

Feel free to contact us.

Commotion is led by the Open Technology Institute.

Open Technology Institute logo

@@ -159,6 +159,21 @@

About

+ + + diff --git a/test.commotion/_site/about/license-privacy/index.html b/test.commotion/_site/about/license-privacy/index.html index 945ccd0d..59b8114d 100644 --- a/test.commotion/_site/about/license-privacy/index.html +++ b/test.commotion/_site/about/license-privacy/index.html @@ -1,4 +1,3 @@ - @@ -17,7 +16,7 @@ -
+
@@ -31,6 +30,7 @@
+ @@ -107,13 +107,7 @@

License & Privacy

-
- -

This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.

Commotion Wireless
-Copyright (C) 2013 Josh King

Privacy Policy for commotionwireless.net

The Open Technology Institute is committed to protecting your online privacy. The following explains what information we collect about you, how we use it and what choices you have regarding this information. This policy applies to all information collected from or submitted to commotionwireless.net.

What We Know About You

As with all Web sites, this site automatically recognizes your domain name, IP address, browser version, operating system and the referring site you passed through to reach our site. We utilize Piwik for site analytics run locally on our servers, so your browsing on this site is not tracked by or submitted to any third party. Any additional information you provide us -- such as your name, organization, address, telephone number, e-mail address and interests -- is collected only upon your request. You must, for example, provide such information whenever you sign up for our email newsletter or make an online contribution.

How We Use "Cookies" and Why

Our site uses "cookies" to improve your navigation through the site and to help us make the site more useful to you. A "cookie" is a small text file on your computer's hard drive that our Web site uses to collect information about how you use our site. The cookie transmits this information back to our Web site each time you visit a page on our site, thus allowing us to identify our most popular pages, features and data. We can then use this information to improve our site to more effectively meet your needs.

How We Use What We Learn

Information we collect is used to improve the content of our sites and to provide you with information or support you've requested. Also, we compile and use this information so that we may keep you apprised of Commotion Wireless events or developments that may be of interest to you.

What We Tell Others About You

We do not furnish to third parties the information that we gather or that you provide to us unless we are legally required to do so.

Links to Other Sites

This site contains links to other sites, including those produced by other organizations. The Open Technology Institute is not responsible for the privacy practices or the contents of any outside sites. As a general rule, links to outside sites are launched in a new browser window, to make clear that you are leaving commotionwireless.net.

Advertising

Commotion Wireless does not accept or display online advertising, and therefore does not work with third-party advertising services. We do, however, promote our own events and publications in various places throughout the site.

Choices You Have

If you wish to discontinue receiving communications from us at any time, please let us know by e-mailing, calling or writing us (see the Contact page). Users who choose to not accept cookies are welcome to use our Web site, but certain features may not be fully available.

We also respect do-not-track preferences available in major web browsers. We also attempt to design our site using progressive enhancement techniques, providing users who choose to block javascript, flash, etc. a full experience of our site while also respecting this choice.

-
- -
+
@@ -133,6 +127,12 @@

About

+
+ +
+ +

This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.

Commotion Wireless
+Copyright (C) 2013 Josh King

Privacy Policy for commotionwireless.net

The Open Technology Institute is committed to protecting your online privacy. The following explains what information we collect about you, how we use it and what choices you have regarding this information. This policy applies to all information collected from or submitted to commotionwireless.net.

What We Know About You

As with all Web sites, this site automatically recognizes your domain name, IP address, browser version, operating system and the referring site you passed through to reach our site. We utilize Piwik for site analytics run locally on our servers, so your browsing on this site is not tracked by or submitted to any third party. Any additional information you provide us -- such as your name, organization, address, telephone number, e-mail address and interests -- is collected only upon your request. You must, for example, provide such information whenever you sign up for our email newsletter or make an online contribution.

How We Use "Cookies" and Why

Our site uses "cookies" to improve your navigation through the site and to help us make the site more useful to you. A "cookie" is a small text file on your computer's hard drive that our Web site uses to collect information about how you use our site. The cookie transmits this information back to our Web site each time you visit a page on our site, thus allowing us to identify our most popular pages, features and data. We can then use this information to improve our site to more effectively meet your needs.

How We Use What We Learn

Information we collect is used to improve the content of our sites and to provide you with information or support you've requested. Also, we compile and use this information so that we may keep you apprised of Commotion Wireless events or developments that may be of interest to you.

What We Tell Others About You

We do not furnish to third parties the information that we gather or that you provide to us unless we are legally required to do so.

Links to Other Sites

This site contains links to other sites, including those produced by other organizations. The Open Technology Institute is not responsible for the privacy practices or the contents of any outside sites. As a general rule, links to outside sites are launched in a new browser window, to make clear that you are leaving commotionwireless.net.

Advertising

Commotion Wireless does not accept or display online advertising, and therefore does not work with third-party advertising services. We do, however, promote our own events and publications in various places throughout the site.

Choices You Have

If you wish to discontinue receiving communications from us at any time, please let us know by e-mailing, calling or writing us (see the Contact page). Users who choose to not accept cookies are welcome to use our Web site, but certain features may not be fully available.

We also respect do-not-track preferences available in major web browsers. We also attempt to design our site using progressive enhancement techniques, providing users who choose to block javascript, flash, etc. a full experience of our site while also respecting this choice.

@@ -155,6 +155,21 @@

About

+ + + diff --git a/test.commotion/_site/about/press/index.html b/test.commotion/_site/about/press/index.html index 969cc5d9..76ce206d 100644 --- a/test.commotion/_site/about/press/index.html +++ b/test.commotion/_site/about/press/index.html @@ -1,4 +1,3 @@ - @@ -17,7 +16,7 @@ -
+
@@ -31,6 +30,7 @@
+ @@ -107,20 +107,7 @@

Press

-
- -

Images and Media

Press Releases & News

Logos & Images

Video

Commotion Development Visualization

 

Commotion is being developed on multiple platforms and through a variety of interacting packages on each platform. The video below visualizes the development process over time. The core Commotion project is at the center, with sub-projects exploding out over time as development ebbs and flows. Branches and leaves represent files and code being added to sub-projects like Android, Tidepools, Linux, and OpenWRT. Read the full blog post.
-Commotion Development Progress from OTI Web Team on Vimeo.

Follow OTI

Twitter logo

-
- -
+
@@ -140,6 +127,19 @@

About

+
+ +
+ +

Images and Media

Press Releases & News

Logos & Images

Video

Commotion Development Visualization

 

Commotion is being developed on multiple platforms and through a variety of interacting packages on each platform. The video below visualizes the development process over time. The core Commotion project is at the center, with sub-projects exploding out over time as development ebbs and flows. Branches and leaves represent files and code being added to sub-projects like Android, Tidepools, Linux, and OpenWRT. Read the full blog post.
+Commotion Development Progress from OTI Web Team on Vimeo.

Follow OTI

Twitter logo

@@ -162,6 +162,21 @@

About

+ + + diff --git a/test.commotion/_site/about/where-its-used/index.html b/test.commotion/_site/about/where-its-used/index.html index 33154be9..2c2c1a81 100644 --- a/test.commotion/_site/about/where-its-used/index.html +++ b/test.commotion/_site/about/where-its-used/index.html @@ -1,4 +1,3 @@ - @@ -17,7 +16,7 @@ -
+
@@ -31,6 +30,7 @@
+ @@ -107,6 +107,28 @@

Where It's Used

+
+ + + + + + + +
+

The Commotion project has pilot networks in Detroit, Red Hook and has built event networks at conferences such as the Allied Media Conference, National Conference for Media Reform, and International Summit for Community Wireless Networks.

International Training in Sayada, Tunisia

Open Technology Institute held a series of workshops on Commotion Wireless technology in Sayada, Tunisia in December 2013.

Learn More:

    @@ -148,28 +170,6 @@

    Where It's Used

Many community wireless networks, running Commotion and other mesh software, can be found on this Wikipedia page. We encourage networks to add themselves to that list as well!

-
- - - - - - - -
-
@@ -190,6 +190,21 @@

About

+ + + diff --git a/test.commotion/_site/access-denied/index.html b/test.commotion/_site/access-denied/index.html index f614a8a3..69627cd3 100644 --- a/test.commotion/_site/access-denied/index.html +++ b/test.commotion/_site/access-denied/index.html @@ -1,4 +1,3 @@ - @@ -17,7 +16,7 @@ -
+
@@ -31,6 +30,7 @@
+ @@ -107,17 +107,17 @@

Access Denied

-
+
-

Sorry! You are not authorized to access this page.

-
-
+
+
+

Sorry! You are not authorized to access this page.

@@ -140,6 +140,21 @@

Access Denied

+ + + diff --git "a/test.commotion/_site/blog/2012/05/01/integrating-design-and-development-shape-commotion\342\200\231s-brand-identity/index.html" "b/test.commotion/_site/blog/2012/05/01/integrating-design-and-development-shape-commotion\342\200\231s-brand-identity/index.html" index 0df08af8..629a90bd 100644 --- "a/test.commotion/_site/blog/2012/05/01/integrating-design-and-development-shape-commotion\342\200\231s-brand-identity/index.html" +++ "b/test.commotion/_site/blog/2012/05/01/integrating-design-and-development-shape-commotion\342\200\231s-brand-identity/index.html" @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,29 +107,7 @@

Integrating design and development to shape Commotion
-
- -

2012-05-01 / The Work Department

- -

At The Work Department, we’ve had the privilege of creating Commotion’s brand identity from conception to completion. If you haven’t heard about it yet, Commotion is an open, yet secure, circumvention tool to create decentralized mesh networks. We are collaboratively developing the tool with The New America Foundation’s Open Technology Initiative. Our challenge was clear: to create an accessible and flexible visual identity for this evolving open source software project. Our early approach was very open – we began with a discovery phase in which we surveyed the Open Technology Initiative (OTI), The Guardian Project, The Serval Project and a few other members of the mesh development community to understand their views on the software. We quickly found a wide range of opinions about aesthetic preferences and public communication strategies for Commotion. We analyzed input from about 15 people and shared the material with OTI to get additional feedback. We made a few conclusions about our direction. First, we planned to embrace potentially different Commotion audiences. Second, we needed something that would be simultaneously utilitarian, accessible, and trustworthy. Third, we wanted to avoid alienating forms that are often presented alongside emerging technologies and represent that mesh technology works in a humanistic way. We began to define our audience as:

-
  • people who seek network connectivity
  • people who seek communication freedom
  • anyone cut off from the internet, whether by Mubarak, Comcast or Katrina
-

We were excited to take on this branding work because we deeply believe in the power of community wireless networking. We wanted to create an identity that we could be proud of – something that would communicate all of the project’s great values and represent our design philosophy. We began creating the identity while development work was also being done on the Commotion software. This rarely happens, so often design is considered the “icing” or top layer in a process while, in reality, we believe design should be integrated at all phases of a development project. We thought a lot about the agility of the design and how it could flex to accommodate the software’s range of current and future functions. Because the software is under development and will be touched by many developers around the world, we imagined a flexible brand system with a range of utilities. For example, the nodes in our design can be modular and be used in different ways. Creating the logo was a vast process. We started by gathering an audit of existing software to understand what else is out there and look at common visual languages. We noticed trends in technology and networking brands and also began to collect graphic elements that might communicate what “mesh” is. From there we started the sketch process on paper. We then narrowed down our ideas and moved into the digital world. You can take a look at our digital sketches in our Flickr pool. Our client and project partners were able to watch our ideas on Flickr and provide us with feedback throughout the entire process. This type of open and collaborative design fuels our philosophy at The Work Department. We are constantly seeking ways to solicit stakeholder and user input to ensure that our products are relevant and accessible. After spending several weeks auditing existing brands and developing our own design ideas, we presented three full brand options to OTI. They were each distinctively different but stemmed from the same overarching goals – meaning they embodied these themes:

-
  • easy to use
  • self determining
  • circumvention
  • utilitarian
  • multiuse
  • generalized
  • versatile
  • humanistic
  • easy to translate in the future (L to R, R to L)
-

You can view our Commotion Identity Proposals here. OTI staff chose the final direction for the identity and we created complete brand identity guidelines. We’re proud to be an integral part of the Commotion project and excited about OTI’s commitment to good design. While other mesh network projects have not created a professional identity, Commotion is being built on a strong foundation of flexible and collaborative design that can be used by all the developers who work on it. This will create lasting consistency and credibility among users, developers, and funders. As designers, this has been a unique opportunity to be involved early in a software development process (instead of at the tail end). We’ve worked with Commotion’s software developers throughout our process. Thanks to this, and our previous experience working on community wireless tools, we are able to significantly inform how the open source development process moves forward. It’s rare that a project takes such an integrated approach – bringing designers and developers together each step of the way. We love working this way, and think that this approach should be used more often. It allows us to ultimately create a better product together – a software tool that offers an outstanding user interface, is credible, is easy to use, and is flexible enough to evolve around the world but maintain a core set of functions and standards. We’re convinced that any software project that integrates designers, developers, and user interface thinkers is far more likely to succeed over the long-term. We’re excited to soon release graphic assets for the Commotion Brand Identity. These files will be publicly available in just a few weeks – check back here for updates!

-

Tags:

- - ui  - - branding  - - identity  - - research  - - -
- -
+

Tags:

@@ -234,6 +213,28 @@

Tags:

hack day (1)
+
+ +
+ +

2012-05-01 / The Work Department

+ +

At The Work Department, we’ve had the privilege of creating Commotion’s brand identity from conception to completion. If you haven’t heard about it yet, Commotion is an open, yet secure, circumvention tool to create decentralized mesh networks. We are collaboratively developing the tool with The New America Foundation’s Open Technology Initiative. Our challenge was clear: to create an accessible and flexible visual identity for this evolving open source software project. Our early approach was very open – we began with a discovery phase in which we surveyed the Open Technology Initiative (OTI), The Guardian Project, The Serval Project and a few other members of the mesh development community to understand their views on the software. We quickly found a wide range of opinions about aesthetic preferences and public communication strategies for Commotion. We analyzed input from about 15 people and shared the material with OTI to get additional feedback. We made a few conclusions about our direction. First, we planned to embrace potentially different Commotion audiences. Second, we needed something that would be simultaneously utilitarian, accessible, and trustworthy. Third, we wanted to avoid alienating forms that are often presented alongside emerging technologies and represent that mesh technology works in a humanistic way. We began to define our audience as:

+
  • people who seek network connectivity
  • people who seek communication freedom
  • anyone cut off from the internet, whether by Mubarak, Comcast or Katrina
+

We were excited to take on this branding work because we deeply believe in the power of community wireless networking. We wanted to create an identity that we could be proud of – something that would communicate all of the project’s great values and represent our design philosophy. We began creating the identity while development work was also being done on the Commotion software. This rarely happens, so often design is considered the “icing” or top layer in a process while, in reality, we believe design should be integrated at all phases of a development project. We thought a lot about the agility of the design and how it could flex to accommodate the software’s range of current and future functions. Because the software is under development and will be touched by many developers around the world, we imagined a flexible brand system with a range of utilities. For example, the nodes in our design can be modular and be used in different ways. Creating the logo was a vast process. We started by gathering an audit of existing software to understand what else is out there and look at common visual languages. We noticed trends in technology and networking brands and also began to collect graphic elements that might communicate what “mesh” is. From there we started the sketch process on paper. We then narrowed down our ideas and moved into the digital world. You can take a look at our digital sketches in our Flickr pool. Our client and project partners were able to watch our ideas on Flickr and provide us with feedback throughout the entire process. This type of open and collaborative design fuels our philosophy at The Work Department. We are constantly seeking ways to solicit stakeholder and user input to ensure that our products are relevant and accessible. After spending several weeks auditing existing brands and developing our own design ideas, we presented three full brand options to OTI. They were each distinctively different but stemmed from the same overarching goals – meaning they embodied these themes:

+
  • easy to use
  • self determining
  • circumvention
  • utilitarian
  • multiuse
  • generalized
  • versatile
  • humanistic
  • easy to translate in the future (L to R, R to L)
+

You can view our Commotion Identity Proposals here. OTI staff chose the final direction for the identity and we created complete brand identity guidelines. We’re proud to be an integral part of the Commotion project and excited about OTI’s commitment to good design. While other mesh network projects have not created a professional identity, Commotion is being built on a strong foundation of flexible and collaborative design that can be used by all the developers who work on it. This will create lasting consistency and credibility among users, developers, and funders. As designers, this has been a unique opportunity to be involved early in a software development process (instead of at the tail end). We’ve worked with Commotion’s software developers throughout our process. Thanks to this, and our previous experience working on community wireless tools, we are able to significantly inform how the open source development process moves forward. It’s rare that a project takes such an integrated approach – bringing designers and developers together each step of the way. We love working this way, and think that this approach should be used more often. It allows us to ultimately create a better product together – a software tool that offers an outstanding user interface, is credible, is easy to use, and is flexible enough to evolve around the world but maintain a core set of functions and standards. We’re convinced that any software project that integrates designers, developers, and user interface thinkers is far more likely to succeed over the long-term. We’re excited to soon release graphic assets for the Commotion Brand Identity. These files will be publicly available in just a few weeks – check back here for updates!

+

Tags:

+ + ui  + + branding  + + identity  + + research  + +
@@ -256,6 +257,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2012/05/08/neighborhood-network-builders-summary/index.html b/test.commotion/_site/blog/2012/05/08/neighborhood-network-builders-summary/index.html index c8de76e2..e4b3f1f1 100644 --- a/test.commotion/_site/blog/2012/05/08/neighborhood-network-builders-summary/index.html +++ b/test.commotion/_site/blog/2012/05/08/neighborhood-network-builders-summary/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,31 +107,7 @@

Neighborhood network builders- a summary

-
- -

2012-05-08 / The Work Department

- -

As part of our research for the Commotion Human Interface Guidelines, we interviewed four people who have been involved in building community wireless networks around Detroit (see earlier blog posts for excerpts). Based on these interviews and our experience working with various users, we recommend that Commotion developers and organizers implement the following concepts: Building successful software Our interviews confirmed that users expect long-term reliability, speed, and ease of use when using wireless devices. The Commotion user interface should:

-
  1. Walk a user through the setup process.
  2. Work well across platforms, browsers, and devices.
  3. Be as fast as using a non-mesh WiFi access point.
  4. Help users understand mesh network security.
  5. Allow for easy monitoring of network status in terms that users can understand.
  6. Offer troubleshooting suggestions when a network does not work correctly.
-

Building a successful neighborhood network

-
  1. Start with dedicated individuals and neighborhood institutions (community centers, housing complexes, churches, and schools).
  2. Offer clear and accessible guidance or training for how to create a network without deep technical expertise.
  3. Give neighbors the tools to teach others about why a network is useful and how to use it.
  4. Engage young people as managers and/or promoters of a network.
  5. Offer simple but useful applications for neighbors to use in the early stages of a network. These should be applications that concretely improve their lives or communication with one another. Introduce more advanced applications only once a community has some experience and comfort using simple applications.
-

</div>

-

Tags:

- - ui  - - detroit  - - community wireless  - - research  - - recommendations  - - -
- -
+

Tags:

@@ -236,6 +213,30 @@

Tags:

hack day (1)
+
+ +
+ +

2012-05-08 / The Work Department

+ +

As part of our research for the Commotion Human Interface Guidelines, we interviewed four people who have been involved in building community wireless networks around Detroit (see earlier blog posts for excerpts). Based on these interviews and our experience working with various users, we recommend that Commotion developers and organizers implement the following concepts: Building successful software Our interviews confirmed that users expect long-term reliability, speed, and ease of use when using wireless devices. The Commotion user interface should:

+
  1. Walk a user through the setup process.
  2. Work well across platforms, browsers, and devices.
  3. Be as fast as using a non-mesh WiFi access point.
  4. Help users understand mesh network security.
  5. Allow for easy monitoring of network status in terms that users can understand.
  6. Offer troubleshooting suggestions when a network does not work correctly.
+

Building a successful neighborhood network

+
  1. Start with dedicated individuals and neighborhood institutions (community centers, housing complexes, churches, and schools).
  2. Offer clear and accessible guidance or training for how to create a network without deep technical expertise.
  3. Give neighbors the tools to teach others about why a network is useful and how to use it.
  4. Engage young people as managers and/or promoters of a network.
  5. Offer simple but useful applications for neighbors to use in the early stages of a network. These should be applications that concretely improve their lives or communication with one another. Introduce more advanced applications only once a community has some experience and comfort using simple applications.
+

</div>

+

Tags:

+ + ui  + + detroit  + + community wireless  + + research  + + recommendations  + +
@@ -258,6 +259,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2012/05/09/audit-current-commotion-user-interfaces/index.html b/test.commotion/_site/blog/2012/05/09/audit-current-commotion-user-interfaces/index.html index 5632ac6d..f0d897ec 100644 --- a/test.commotion/_site/blog/2012/05/09/audit-current-commotion-user-interfaces/index.html +++ b/test.commotion/_site/blog/2012/05/09/audit-current-commotion-user-interfaces/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,42 +107,7 @@

An audit of current Commotion user interfaces

-
- -

2012-05-09 / The Work Department

- -

With the goal of creating both an intuitive and accessible user experience (UX) across a sampling of devices that will run Commotion, we surveyed and analyzed the current state of the existing interfaces. We deployed a test network using the three software components currently in development phases: Commotion on an Ubiquiti Picostation (router), The Guardian Project’s OLSR Mesh Tether on an Android handset (phone) and Commotion on Linux (laptop). In anticipation of The Serval Project’s forthcoming work around meshing mobile devices with Commotion, we also researched the current release of Serval Mesh. We documented each step with screenshots, which are compiled here. After the initial audit, we compared and contrasted each workflow, documenting any issues that arose during the process and were then able to make recommendations on how to improve each of the interfaces and workflows and make them consistent across platforms. Our process was unique in that our auditors represented a range of skill levels and backgrounds. We seek to represent this diversity when creating user interfaces that are intended for a broad range of users. For example, Auditor 1 is a self-taught web developer with advanced skills in networks and mesh networks specifically. Auditor 2 is a designer with intermediate knowledge of networks and some experience setting up networks. Auditor 3 is a designer with basic network skills and very little experience setting up a network. We feel that these varied levels of experience with networking are important. The advanced user can help guide the process for successful installation and the inexperienced users can communicate what is helpful while illuminating confusing aspects of the process. Commotion Router: Installing on an Ubiquiti Picostation (See a PDF of the process.) The router interface and workflow was the most complex of the three platforms we tested. The welcome screen includes rules for accessing the network and the option to “accept” or “decline” access. Though that seems straightforward, after clicking “accept” we were redirected to an error message, “302 found.” With no explanation of what caused the error or what to do next, we manually typed in the router’s IP address to attempt to access the network. This seemed to work, as we were then taken to the Commotion login page. The default settings do not require a username and password, though this is not noted anywhere, so we clicked the “login” button and were taken to (another) welcome screen. This welcome screen told us that we were now connected to a mesh network and included a description of what Commotion is, with a link to even more information about the project. To configure the settings of the mesh network, we clicked on “Administration,” which was a link in the upper right corner. Once inside the Administration section, the menu links on the left changed. Initially, the left menu had one link: “Overview.” When inside the Administration section, the menu no longer includes “Overview” but changes to include “Commotion, Status, System, Services, Network, Statistics, Logout, and Voice” links. From the “Commotion” menu we selected “Mesh Config (Manual).” Confusingly, when selecting the “Commotion” menu the “Status” menu link changed color as if we were selecting it instead. Also, the link in the menu is called “Mesh Config (Manual),” though when on this page, the title is “Configuration.” From the “Configuration” page we changed the base-name from “commotion_52_51” to our custom network name “meshshaging.” We then clicked “Save & Apply.” A loading wheel spun and read “waiting for router,” however no validation message ever appeared. A line of text at the top of the pages suggested rebooting the node after changing any settings, so we found the link to “Reboot” under the “System” menu. We were taken to another screen where we could select “Perform Reboot.” A message appeared reading “Please wait: Device rebooting” However, we never saw any validation message. Once the device was rebooted, which we noticed from watching the status lights on the actual device, we verified that the network had been renamed via the airport/wireless window. This process is also documented in the UX flowchart here. OLSR Mesh Tether Phone: Installing on an Android handset (See a PDF of the process.) Once the OLSR Mesh Tether was installed on the Android device, and the program was launched, we were taken to a screen showing a log of activity, a “Traffic” button, a “Clients” button and a large “Start” button. In order to access the settings, we had to push the physical “Settings” button on the handset, not in the interface. This menu was a long list of settings, some with a bit of explanation underneath and some without any explanation. We selected “SSID” which was the first listing in the settings. A pop-up appeared titled “SSID (Network Name)” with a default value of “olsr.org” and an “OK” and “cancel” button. We changed the name to “meshshaging” and selected “OK.” We then were back at the main Settings menu, where we selected “Channel,” which was third in the list of settings. A pop-up appeared with the title “Channel” and a list of channels, from 1-12, to choose from each with a channel number and the corresponding frequency. We selected channel 7 and were taken back to the main settings menu. These steps are the only steps required to set up the mesh, but when we tried to access the network we received an error message titled, “Root Access,” telling us we needed to have root access in order for the software to actually work. So our process with the Android device had to end there. This process is also documented in the UX flowchart here. Serval Mesh Phone: Installing on an Android handset (See a PDF of the process.) We also looked at the Serval Mesh software on the Android device. The current release of Serval Mesh creates a mesh-based self-powered and self-organizing phone network between WiFi-enabled phones that requires no other infrastructure. We chose to evaluate Serval’s interface as well, because it relies on mesh networks and many of the settings might be similar. When Serval Mesh is launched, the first screen is not a welcome message, but a warning titled “HERE BE DRAGONS!” and a long paragraph about the program still being in development and containing various bugs, and that it may interfere with normal use of your phone. There is an “I Agree” and a “Cancel” button. We chose “I Agree” and were taken to the “Setup Instructions.” The instructions told us that we would have to pick a phone number, which cannot start with “11” and must have more than 5 digits. There is an “OK” button that we clicked after thinking about a number. Then we were prompted to enter the number we chose, which we did, and clicked “OK” - phone calls could now be made. This process is also documented in the UX flowchart here. Commotion Laptop: Installation on a laptop running Linux This installation process has no graphic user interface. All commands are via terminal input and only an experienced user could have success navigating this process. The commands are below and the following analysis is limited.

- -
# add guardian&#39;s ppa
-apt-get update
-apt-get install olsrd
-# edit /etc/olsrd/olsrd.conf: set DebugLevel to 1, change Interface to your wifi card
-sudo service stop network-manager
-sudo ifconfig wlan0 up
-sudo ifconfig wlan0 5.70.60.60 netmask 255.0.0.0
-olsrd -f /etc/olsrd/olsrd.conf
- -

Shared actions: Commotion router, OLSR Mesh Tether phone and Serval Mesh phone The Commotion Router and Serval Mesh processes start with a splash page that includes a welcome/warning, more information, and the choice to either continue or cancel. The OLSR Mesh Tether and Commotion Linux processes don’t have any initial instruction or more information about the software. From this point in the workflow, all of the processes become equally unclear as to what is necessary to configure the network. The Commotion Linux and OLSR Mesh Tether interfaces are the least informative. The OLSR Mesh Tether user interface (UI) offers only a few hints as to what is optional and rarely defines terminology. The Linux application, as it is run from the terminal, offers no hints or help at all. The Commotion Router UI has the most information - because it is accessed from a laptop and not a handheld device, there is plenty of “space” to feature this much detail. But while there is more detail and are more options, there is no guidance and the process far from intuitive. As auditors, we conclude that without programming or mesh-networking experience, the chances for users to successfully configure a network are slim. See the flowcharts side-by-side here. Shared language Each of the interfaces has a unique way of communicating the purpose of the software when it is first launched. The Commotion Router welcome screen never says the word “mesh” but instead calls the project a “community wireless network.” The OLSR Mesh Tether interface has the title “OLSR Mesh Tether” but no other mention of “mesh” or “network[ing].” The Serval Mesh interface’s warning/welcome screen has both the words “mesh” and “networking,” but they are buried deep in the warning. The Linux language includes native terminal cues and the word “network” but not “mesh.” On both the Serval Mesh and Commotion Router interfaces, there is a button on the welcome screen that allows you to cancel or move further into the process but the language used here is different as well. The Serval Mesh UI buttons are labeled “I agree” and “Cancel.” The Commotion Router UI buttons are labeled “Decline” and “Accept.” The OLSR Mesh Tether and Linux interfaces do not include these buttons at all. The Serval Mesh software seems to automatically configure the settings and the other applications do not. Though the same settings need to be configured, the language referring to some of the settings is not the same. The OLSR Mesh Tether interface refers to the SSID as “SSID (Network Name)” while the router interface refers to it as “Mesh SSID.” In addition, the essential settings are in menus labeled in two different ways: the OLSR Mesh Tether menu is labeled ”Wireless LAN” and the router interface menu is labeled “Configuration.” The language surrounding choosing a channel is the same in both interfaces, though it is not a required step in the router interface. Initial recommendations Among the audited software, we discovered that there is a lack of an shared language. In order to create the foundation for a seamless, connected, and accessible platform, a Commotion set of themes, actions and icons are essential. After this discovery phase, we conclude that these are four focus areas that will drastically improve the overall user experience. These focus areas are in addition to applying the new Commotion brand identity.

-

1. Common Language

-

Shared language is essential in order to make Commotion accessible to the general public. In addition to using a common set of themes, actions and icons, we recommend adding hints or tooltips as much as possible. For example, a hint could be added to the SSID field that tells the user “The SSID should be a unique name for your community network and can be up to xx characters.” This would make it clearer to a beginner user what is expected in each field. Moreover, we recommend that the language on buttons, menus and messages be replaced with more action-oriented and explanatory language. The first buttons the user is faced with in the Serval, router and Android interfaces are “I Agree/Cancel,” “Accept/Decline” and “Start,” respectively. The action the user is agreeing to would be more evident if the buttons were named, for example, “Link Up” and “Not Now."

-

2. Workflow Hierarchy

-

Designing a way to designate required fields and optional fields would be helpful for new users. If this were done, a beginner would know that only two clear steps (hypothetically) are needed to configure the network and that not all settings are needed to simply link to the mesh network. Beyond this, we recommend that two groups of settings, required and optional, be separated hierarchically to make it even more clear to a new user what is needed and to an advanced user where more changes can be made. The interface should also include a link to more information about the settings and how to choose a channel or SSID, for the user who would like to self-educate.

-

3. Join an existing network or build a new network?

-

Throughout all of the UI, it is never clear what actions should be taken by a user when they are either joining an existing network or building a new network. It may be useful to create initial prompts that clarify whether the device is detecting and, thus, linking to an existing network or not. It may be important to note whether the device, or node, is acting as the first node in a new network. It may also be useful to show whether or not a network is connected to the global Internet. In the future, icons can be created that communicate how nodes are connected and how traffic is flowing across the network. This may be similar to a visualization/mapping tool, like Open Mesh’s cloudtrax.com network management tool.

-

4. Connectivity and configuration validation

-

Finally, we recommend a positive message, sound or validation feature when the network has been successfully configured and instructions on what to do next. As of now, the user is just left to assume (or not) that the settings they have entered are valid. A progress wheel, or something similar, is also recommended where appropriate, as it gives the user a sense of progress when going through the installation and configuration process. An example can be found with the OLSR Mesh Tether device error message. The message told us that the device needed to be rooted in order to proceed, but with little experience in development for handheld devices, a user will not be familiar with what the term “root” means and will be left with no pathway to move forward.

-

Tags:

- - ui  - - ux  - - research  - - -
- -
+

Tags:

@@ -247,6 +213,41 @@

Tags:

hack day (1)
+
+ +
+ +

2012-05-09 / The Work Department

+ +

With the goal of creating both an intuitive and accessible user experience (UX) across a sampling of devices that will run Commotion, we surveyed and analyzed the current state of the existing interfaces. We deployed a test network using the three software components currently in development phases: Commotion on an Ubiquiti Picostation (router), The Guardian Project’s OLSR Mesh Tether on an Android handset (phone) and Commotion on Linux (laptop). In anticipation of The Serval Project’s forthcoming work around meshing mobile devices with Commotion, we also researched the current release of Serval Mesh. We documented each step with screenshots, which are compiled here. After the initial audit, we compared and contrasted each workflow, documenting any issues that arose during the process and were then able to make recommendations on how to improve each of the interfaces and workflows and make them consistent across platforms. Our process was unique in that our auditors represented a range of skill levels and backgrounds. We seek to represent this diversity when creating user interfaces that are intended for a broad range of users. For example, Auditor 1 is a self-taught web developer with advanced skills in networks and mesh networks specifically. Auditor 2 is a designer with intermediate knowledge of networks and some experience setting up networks. Auditor 3 is a designer with basic network skills and very little experience setting up a network. We feel that these varied levels of experience with networking are important. The advanced user can help guide the process for successful installation and the inexperienced users can communicate what is helpful while illuminating confusing aspects of the process. Commotion Router: Installing on an Ubiquiti Picostation (See a PDF of the process.) The router interface and workflow was the most complex of the three platforms we tested. The welcome screen includes rules for accessing the network and the option to “accept” or “decline” access. Though that seems straightforward, after clicking “accept” we were redirected to an error message, “302 found.” With no explanation of what caused the error or what to do next, we manually typed in the router’s IP address to attempt to access the network. This seemed to work, as we were then taken to the Commotion login page. The default settings do not require a username and password, though this is not noted anywhere, so we clicked the “login” button and were taken to (another) welcome screen. This welcome screen told us that we were now connected to a mesh network and included a description of what Commotion is, with a link to even more information about the project. To configure the settings of the mesh network, we clicked on “Administration,” which was a link in the upper right corner. Once inside the Administration section, the menu links on the left changed. Initially, the left menu had one link: “Overview.” When inside the Administration section, the menu no longer includes “Overview” but changes to include “Commotion, Status, System, Services, Network, Statistics, Logout, and Voice” links. From the “Commotion” menu we selected “Mesh Config (Manual).” Confusingly, when selecting the “Commotion” menu the “Status” menu link changed color as if we were selecting it instead. Also, the link in the menu is called “Mesh Config (Manual),” though when on this page, the title is “Configuration.” From the “Configuration” page we changed the base-name from “commotion_52_51” to our custom network name “meshshaging.” We then clicked “Save & Apply.” A loading wheel spun and read “waiting for router,” however no validation message ever appeared. A line of text at the top of the pages suggested rebooting the node after changing any settings, so we found the link to “Reboot” under the “System” menu. We were taken to another screen where we could select “Perform Reboot.” A message appeared reading “Please wait: Device rebooting” However, we never saw any validation message. Once the device was rebooted, which we noticed from watching the status lights on the actual device, we verified that the network had been renamed via the airport/wireless window. This process is also documented in the UX flowchart here. OLSR Mesh Tether Phone: Installing on an Android handset (See a PDF of the process.) Once the OLSR Mesh Tether was installed on the Android device, and the program was launched, we were taken to a screen showing a log of activity, a “Traffic” button, a “Clients” button and a large “Start” button. In order to access the settings, we had to push the physical “Settings” button on the handset, not in the interface. This menu was a long list of settings, some with a bit of explanation underneath and some without any explanation. We selected “SSID” which was the first listing in the settings. A pop-up appeared titled “SSID (Network Name)” with a default value of “olsr.org” and an “OK” and “cancel” button. We changed the name to “meshshaging” and selected “OK.” We then were back at the main Settings menu, where we selected “Channel,” which was third in the list of settings. A pop-up appeared with the title “Channel” and a list of channels, from 1-12, to choose from each with a channel number and the corresponding frequency. We selected channel 7 and were taken back to the main settings menu. These steps are the only steps required to set up the mesh, but when we tried to access the network we received an error message titled, “Root Access,” telling us we needed to have root access in order for the software to actually work. So our process with the Android device had to end there. This process is also documented in the UX flowchart here. Serval Mesh Phone: Installing on an Android handset (See a PDF of the process.) We also looked at the Serval Mesh software on the Android device. The current release of Serval Mesh creates a mesh-based self-powered and self-organizing phone network between WiFi-enabled phones that requires no other infrastructure. We chose to evaluate Serval’s interface as well, because it relies on mesh networks and many of the settings might be similar. When Serval Mesh is launched, the first screen is not a welcome message, but a warning titled “HERE BE DRAGONS!” and a long paragraph about the program still being in development and containing various bugs, and that it may interfere with normal use of your phone. There is an “I Agree” and a “Cancel” button. We chose “I Agree” and were taken to the “Setup Instructions.” The instructions told us that we would have to pick a phone number, which cannot start with “11” and must have more than 5 digits. There is an “OK” button that we clicked after thinking about a number. Then we were prompted to enter the number we chose, which we did, and clicked “OK” - phone calls could now be made. This process is also documented in the UX flowchart here. Commotion Laptop: Installation on a laptop running Linux This installation process has no graphic user interface. All commands are via terminal input and only an experienced user could have success navigating this process. The commands are below and the following analysis is limited.

+ +
# add guardian&#39;s ppa
+apt-get update
+apt-get install olsrd
+# edit /etc/olsrd/olsrd.conf: set DebugLevel to 1, change Interface to your wifi card
+sudo service stop network-manager
+sudo ifconfig wlan0 up
+sudo ifconfig wlan0 5.70.60.60 netmask 255.0.0.0
+olsrd -f /etc/olsrd/olsrd.conf
+ +

Shared actions: Commotion router, OLSR Mesh Tether phone and Serval Mesh phone The Commotion Router and Serval Mesh processes start with a splash page that includes a welcome/warning, more information, and the choice to either continue or cancel. The OLSR Mesh Tether and Commotion Linux processes don’t have any initial instruction or more information about the software. From this point in the workflow, all of the processes become equally unclear as to what is necessary to configure the network. The Commotion Linux and OLSR Mesh Tether interfaces are the least informative. The OLSR Mesh Tether user interface (UI) offers only a few hints as to what is optional and rarely defines terminology. The Linux application, as it is run from the terminal, offers no hints or help at all. The Commotion Router UI has the most information - because it is accessed from a laptop and not a handheld device, there is plenty of “space” to feature this much detail. But while there is more detail and are more options, there is no guidance and the process far from intuitive. As auditors, we conclude that without programming or mesh-networking experience, the chances for users to successfully configure a network are slim. See the flowcharts side-by-side here. Shared language Each of the interfaces has a unique way of communicating the purpose of the software when it is first launched. The Commotion Router welcome screen never says the word “mesh” but instead calls the project a “community wireless network.” The OLSR Mesh Tether interface has the title “OLSR Mesh Tether” but no other mention of “mesh” or “network[ing].” The Serval Mesh interface’s warning/welcome screen has both the words “mesh” and “networking,” but they are buried deep in the warning. The Linux language includes native terminal cues and the word “network” but not “mesh.” On both the Serval Mesh and Commotion Router interfaces, there is a button on the welcome screen that allows you to cancel or move further into the process but the language used here is different as well. The Serval Mesh UI buttons are labeled “I agree” and “Cancel.” The Commotion Router UI buttons are labeled “Decline” and “Accept.” The OLSR Mesh Tether and Linux interfaces do not include these buttons at all. The Serval Mesh software seems to automatically configure the settings and the other applications do not. Though the same settings need to be configured, the language referring to some of the settings is not the same. The OLSR Mesh Tether interface refers to the SSID as “SSID (Network Name)” while the router interface refers to it as “Mesh SSID.” In addition, the essential settings are in menus labeled in two different ways: the OLSR Mesh Tether menu is labeled ”Wireless LAN” and the router interface menu is labeled “Configuration.” The language surrounding choosing a channel is the same in both interfaces, though it is not a required step in the router interface. Initial recommendations Among the audited software, we discovered that there is a lack of an shared language. In order to create the foundation for a seamless, connected, and accessible platform, a Commotion set of themes, actions and icons are essential. After this discovery phase, we conclude that these are four focus areas that will drastically improve the overall user experience. These focus areas are in addition to applying the new Commotion brand identity.

+

1. Common Language

+

Shared language is essential in order to make Commotion accessible to the general public. In addition to using a common set of themes, actions and icons, we recommend adding hints or tooltips as much as possible. For example, a hint could be added to the SSID field that tells the user “The SSID should be a unique name for your community network and can be up to xx characters.” This would make it clearer to a beginner user what is expected in each field. Moreover, we recommend that the language on buttons, menus and messages be replaced with more action-oriented and explanatory language. The first buttons the user is faced with in the Serval, router and Android interfaces are “I Agree/Cancel,” “Accept/Decline” and “Start,” respectively. The action the user is agreeing to would be more evident if the buttons were named, for example, “Link Up” and “Not Now."

+

2. Workflow Hierarchy

+

Designing a way to designate required fields and optional fields would be helpful for new users. If this were done, a beginner would know that only two clear steps (hypothetically) are needed to configure the network and that not all settings are needed to simply link to the mesh network. Beyond this, we recommend that two groups of settings, required and optional, be separated hierarchically to make it even more clear to a new user what is needed and to an advanced user where more changes can be made. The interface should also include a link to more information about the settings and how to choose a channel or SSID, for the user who would like to self-educate.

+

3. Join an existing network or build a new network?

+

Throughout all of the UI, it is never clear what actions should be taken by a user when they are either joining an existing network or building a new network. It may be useful to create initial prompts that clarify whether the device is detecting and, thus, linking to an existing network or not. It may be important to note whether the device, or node, is acting as the first node in a new network. It may also be useful to show whether or not a network is connected to the global Internet. In the future, icons can be created that communicate how nodes are connected and how traffic is flowing across the network. This may be similar to a visualization/mapping tool, like Open Mesh’s cloudtrax.com network management tool.

+

4. Connectivity and configuration validation

+

Finally, we recommend a positive message, sound or validation feature when the network has been successfully configured and instructions on what to do next. As of now, the user is just left to assume (or not) that the settings they have entered are valid. A progress wheel, or something similar, is also recommended where appropriate, as it gives the user a sense of progress when going through the installation and configuration process. An example can be found with the OLSR Mesh Tether device error message. The message told us that the device needed to be rooted in order to proceed, but with little experience in development for handheld devices, a user will not be familiar with what the term “root” means and will be left with no pathway to move forward.

+

Tags:

+ + ui  + + ux  + + research  + +
@@ -269,6 +270,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2012/05/30/building-successful-online-community-open-source-development/index.html b/test.commotion/_site/blog/2012/05/30/building-successful-online-community-open-source-development/index.html index e73a5747..e0530eee 100644 --- a/test.commotion/_site/blog/2012/05/30/building-successful-online-community-open-source-development/index.html +++ b/test.commotion/_site/blog/2012/05/30/building-successful-online-community-open-source-development/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,23 +107,7 @@

Building successful online community for open-source de
-
- -

2012-05-30 / The Work Department

- -

In order to help build the most effective Commotion online community, we’ve conducted basic research to gain an understanding of infrastructures that other software development communities use. We focused on open-source projects that are used widely. We found that, while a variety of communication strategies, governance structures, and social cultures exist, there are some shared elements that appear to make a community strong and effective. In our full report to the Open Technology Initiative, we reviewed Drupal, Mozilla, Android, and Ubuntu Linux. In this post, we include a simplified comparison of those communities and share the conclusions we drew from our research. Overview
See an overview of some large open-source projects (PDF)
Recommendations for Commotion Online Presence Because Commotion is a new and evolving project, we see an excellent opportunity to build an effective online community by implementing the best practices used by other open-source communities. Commotion’s online presence should easily direct different audiences (developers, users, journalists, funders) to the information they need the most while encouraging community interaction and collaboration. Potential Site Outline Based on our current understanding of Commotion’s needs, we’ve created the following simple outline for the project’s complete website. We will develop a more detailed sitemap in the next phase of our work. Over time, of course, the Commotion website should evolve to meet the needs of developers and users. This will require that Commotion leaders pay close attention to those needs and quickly respond to feedback and innovation from the community.

-
  1. commotionwireless.net Home Page (include a Get Involved area and Getting Started area)
  2. Blog (managed by an editing team or committee)
  3. About
  4. Documentation
    • User Manual
    • Design Guidelines
    • Human Interface Guidelines
    • Community Governance
  5. Project Partners (Open Technology Initiative, Guardian Project, OpenBTS, Serval Project)
  6. Developers (goes to https://code.commotionwireless.net)
  7. Press
-

Open Governance In order to promote long-term investment and encourage a wide array of contributors to get involved, we recommend that OTI establish a clear and written governance structure for the Commotion project. This should include roles of various people in the community and general expectations for how contributors should work together and make key decisions. Many examples are available from other projects. The governance structure should be posted on the Commotion site and be recommended reading for all newcomers to the project. This will help contributors understand how they can be involved and how their work will be valued. Future Considerations Translation and other localization work should be planned at an appropriate time in the future. The communities that we evaluated each have specific areas of their sites dedicated to localization efforts. This is also a good opportunity for non-programmers to contribute to the project. Want more? Read our full report at the Commotion wiki.

-

Tags:

- - recommendations  - - research  - - -
- -
+

Tags:

@@ -228,6 +213,22 @@

Tags:

hack day (1)
+
+ +
+ +

2012-05-30 / The Work Department

+ +

In order to help build the most effective Commotion online community, we’ve conducted basic research to gain an understanding of infrastructures that other software development communities use. We focused on open-source projects that are used widely. We found that, while a variety of communication strategies, governance structures, and social cultures exist, there are some shared elements that appear to make a community strong and effective. In our full report to the Open Technology Initiative, we reviewed Drupal, Mozilla, Android, and Ubuntu Linux. In this post, we include a simplified comparison of those communities and share the conclusions we drew from our research. Overview
See an overview of some large open-source projects (PDF)
Recommendations for Commotion Online Presence Because Commotion is a new and evolving project, we see an excellent opportunity to build an effective online community by implementing the best practices used by other open-source communities. Commotion’s online presence should easily direct different audiences (developers, users, journalists, funders) to the information they need the most while encouraging community interaction and collaboration. Potential Site Outline Based on our current understanding of Commotion’s needs, we’ve created the following simple outline for the project’s complete website. We will develop a more detailed sitemap in the next phase of our work. Over time, of course, the Commotion website should evolve to meet the needs of developers and users. This will require that Commotion leaders pay close attention to those needs and quickly respond to feedback and innovation from the community.

+
  1. commotionwireless.net Home Page (include a Get Involved area and Getting Started area)
  2. Blog (managed by an editing team or committee)
  3. About
  4. Documentation
    • User Manual
    • Design Guidelines
    • Human Interface Guidelines
    • Community Governance
  5. Project Partners (Open Technology Initiative, Guardian Project, OpenBTS, Serval Project)
  6. Developers (goes to https://code.commotionwireless.net)
  7. Press
+

Open Governance In order to promote long-term investment and encourage a wide array of contributors to get involved, we recommend that OTI establish a clear and written governance structure for the Commotion project. This should include roles of various people in the community and general expectations for how contributors should work together and make key decisions. Many examples are available from other projects. The governance structure should be posted on the Commotion site and be recommended reading for all newcomers to the project. This will help contributors understand how they can be involved and how their work will be valued. Future Considerations Translation and other localization work should be planned at an appropriate time in the future. The communities that we evaluated each have specific areas of their sites dedicated to localization efforts. This is also a good opportunity for non-programmers to contribute to the project. Want more? Read our full report at the Commotion wiki.

+

Tags:

+ + recommendations  + + research  + +
@@ -250,6 +251,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2012/08/22/exploring-meshaging/index.html b/test.commotion/_site/blog/2012/08/22/exploring-meshaging/index.html index 81858dee..27485f2b 100644 --- a/test.commotion/_site/blog/2012/08/22/exploring-meshaging/index.html +++ b/test.commotion/_site/blog/2012/08/22/exploring-meshaging/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,21 +107,7 @@

Exploring "meshaging"

-
- -

2012-08-22 / The Work Department

- -

Over the past few years, The Work Department has been active in building community wireless networks in Detroit. We have experimented with different types of hardware and software, and we have helped neighborhoods build useful networks to share internet connectivity and provide local file sharing. Something we haven’t had much of an opportunity to explore, though, is building more elaborate systems that leverage the unique traits of mesh networks. As we worked through other parts of the Commotion project, we brainstormed ideas for wireless mesh applications. We noticed that our ideas would often replicate existing web services — e.g. a local fileserver for music or movies, or a local message board for neighborhood discussion. We began to wonder what would make a community wireless application more appealing than using a centralized Internet-based application. We agreed that it wouldn’t be enough to offer someone the simple satisfaction of knowing their data is decentralized… there would need to be some other benefits to using a local application. What would these benefits be? What is special about the architecture of a community wireless mesh network? In pondering these questions, we considered what is provided by these networks — earlier, I mentioned that the networks provide internet connection sharing and local file sharing, but that’s only a part of the story. These networks also provide something much grander: they become community institutions. Unlike the Comcast hardware that is bolted out of arm’s reach on a utility pole, our community wireless equipment lives on our porches, in chicken coops, in our bell towers, and next to our desks. Each piece of equipment has a story behind it. We know who held the ladder while it was being installed and who lent their hammer drill to run a cable up to it. A community mesh wireless router’s IP address is more than a 32-bit number. It has history and meaning. How can we build applications that reflect and enhance this? I had the good fortune to meet Adam Magaluk at Detroit’s hackerspace, OmniCorpDetroit. Adam works on mesh wireless systems at Illuminating Concepts, and is deeply interested in OLSR and embedded systems. We are both young programmers and share a preference for modular and decentralized systems. During our initial conversations and research, we ended up favoring web browser based application development. This way, people who might want to use an application wouldn’t have to download anything. Since today’s web browsers have lightweight streaming messaging capabilities with WebSocket, we would have a lot of flexibility in application development. To build a web browser based application, we can start by limiting the amount of work the server does to a bare minimum. In the circumstance of a chat application, we can say that the server should simply keep a record of who is connected to a chat session (in a sort of subscription model) and then, as messages are posted, transfer messages from the publisher to the subscribers. Limiting the duties of each mesh node to passing messages and keeping track of connected clients ends up being beneficial in two ways: it conserves computing resources and encourages decentralized application development. Since most community wireless routers are low power, low cost devices running with MIPS CPUs and 4-16GB memory, the former benefit is clearly attractive. The latter benefit is a bit more complex — do we really need a fully decentralized application? Why can’t we just have a little bit of local node storage? It sure would make things simpler if we could have a local data cache instead of trying to develop a peer-to-peer storage system, but for now we’ll embrace this limitation when designing applications. To begin experimenting with the core concepts of lightweight messaging systems that can work with community wireless network hardware, we built an example application to provide WebSocket service to clients connected to a Commotion access point. This service can be utilized by anything on the network, but in our first example application, it is employed by a web application served from a publicly accessible LuCI URI linked from the splash page. The application provides a simple interface to chat with other people who have connected to the local node’s websocket chat system. Thanks to the work of Hans-Christoph Steiner (from The Guardian Project) on the jsoninfo plugin, OLSRd can easily provide some useful network information as a json object to web applications. Above the network layer, our WebSocket message server can provide data about connected clients and possibly other information in the future. After you get your head wrapped around the WebSocket server, its underlying restrictions, and the mesh network playing field, you can start to imagine various situations where local messaging might be interesting. With an idea in mind, a developer can easily jump into a familiar web application development environment. If you have used things like WebSockets or socket.io, you already understand the core concepts of writing a mesh network application using these building blocks. As we build more features into the platform, it will offer more options for developers. Next Steps Currently, the system provides a messaging service that doesn’t utilize node-to-node mesh connections. As it stands, we can develop some interesting and useful applications, but there is definitely a lot to gain from adding functionality and possibly revamping things in the interest of security or privacy. Our next major task is to begin experimenting with systems that- allow neighboring nodes to subscribe to each others’ connections. To use the chat application as an example of how this might be used: a chat participant might be able to start a conversation with people connected to their own mesh node and its next neighbors, or some other arbitrary number of hops. We would also like to experiment with simple implementations of shared / distributed storage. Again, to use the chat system as an illustration, we could have chat participants store chat logs and offer them to new participants who broadcast a request for the last N minutes of conversation. There is a lot of distributed storage work for us to reference, of course, so we have our work cut out for us! Aside f/rom enhancements and features in the messaging system itself, we have plenty of ideas for the actual applications. We have recently been prototyping games that could use a neighborhood or multi-neighborhood mesh network as a playing field. We have found that prototyping and brainstorming games is an enlightening process: it helps explain the ins and outs of the technology to people, and also presents clear challenges to create obvious and attainable goals within the technology’s limitations. We’ll be sharing some “capture the flag” style game ideas that utilize a “meshaging” system during the next couple of weeks.

-

Tags:

- - messaging  - - detroit  - - -
- -
+

Tags:

@@ -226,6 +213,20 @@

Tags:

hack day (1)
+
+ +
+ +

2012-08-22 / The Work Department

+ +

Over the past few years, The Work Department has been active in building community wireless networks in Detroit. We have experimented with different types of hardware and software, and we have helped neighborhoods build useful networks to share internet connectivity and provide local file sharing. Something we haven’t had much of an opportunity to explore, though, is building more elaborate systems that leverage the unique traits of mesh networks. As we worked through other parts of the Commotion project, we brainstormed ideas for wireless mesh applications. We noticed that our ideas would often replicate existing web services — e.g. a local fileserver for music or movies, or a local message board for neighborhood discussion. We began to wonder what would make a community wireless application more appealing than using a centralized Internet-based application. We agreed that it wouldn’t be enough to offer someone the simple satisfaction of knowing their data is decentralized… there would need to be some other benefits to using a local application. What would these benefits be? What is special about the architecture of a community wireless mesh network? In pondering these questions, we considered what is provided by these networks — earlier, I mentioned that the networks provide internet connection sharing and local file sharing, but that’s only a part of the story. These networks also provide something much grander: they become community institutions. Unlike the Comcast hardware that is bolted out of arm’s reach on a utility pole, our community wireless equipment lives on our porches, in chicken coops, in our bell towers, and next to our desks. Each piece of equipment has a story behind it. We know who held the ladder while it was being installed and who lent their hammer drill to run a cable up to it. A community mesh wireless router’s IP address is more than a 32-bit number. It has history and meaning. How can we build applications that reflect and enhance this? I had the good fortune to meet Adam Magaluk at Detroit’s hackerspace, OmniCorpDetroit. Adam works on mesh wireless systems at Illuminating Concepts, and is deeply interested in OLSR and embedded systems. We are both young programmers and share a preference for modular and decentralized systems. During our initial conversations and research, we ended up favoring web browser based application development. This way, people who might want to use an application wouldn’t have to download anything. Since today’s web browsers have lightweight streaming messaging capabilities with WebSocket, we would have a lot of flexibility in application development. To build a web browser based application, we can start by limiting the amount of work the server does to a bare minimum. In the circumstance of a chat application, we can say that the server should simply keep a record of who is connected to a chat session (in a sort of subscription model) and then, as messages are posted, transfer messages from the publisher to the subscribers. Limiting the duties of each mesh node to passing messages and keeping track of connected clients ends up being beneficial in two ways: it conserves computing resources and encourages decentralized application development. Since most community wireless routers are low power, low cost devices running with MIPS CPUs and 4-16GB memory, the former benefit is clearly attractive. The latter benefit is a bit more complex — do we really need a fully decentralized application? Why can’t we just have a little bit of local node storage? It sure would make things simpler if we could have a local data cache instead of trying to develop a peer-to-peer storage system, but for now we’ll embrace this limitation when designing applications. To begin experimenting with the core concepts of lightweight messaging systems that can work with community wireless network hardware, we built an example application to provide WebSocket service to clients connected to a Commotion access point. This service can be utilized by anything on the network, but in our first example application, it is employed by a web application served from a publicly accessible LuCI URI linked from the splash page. The application provides a simple interface to chat with other people who have connected to the local node’s websocket chat system. Thanks to the work of Hans-Christoph Steiner (from The Guardian Project) on the jsoninfo plugin, OLSRd can easily provide some useful network information as a json object to web applications. Above the network layer, our WebSocket message server can provide data about connected clients and possibly other information in the future. After you get your head wrapped around the WebSocket server, its underlying restrictions, and the mesh network playing field, you can start to imagine various situations where local messaging might be interesting. With an idea in mind, a developer can easily jump into a familiar web application development environment. If you have used things like WebSockets or socket.io, you already understand the core concepts of writing a mesh network application using these building blocks. As we build more features into the platform, it will offer more options for developers. Next Steps Currently, the system provides a messaging service that doesn’t utilize node-to-node mesh connections. As it stands, we can develop some interesting and useful applications, but there is definitely a lot to gain from adding functionality and possibly revamping things in the interest of security or privacy. Our next major task is to begin experimenting with systems that- allow neighboring nodes to subscribe to each others’ connections. To use the chat application as an example of how this might be used: a chat participant might be able to start a conversation with people connected to their own mesh node and its next neighbors, or some other arbitrary number of hops. We would also like to experiment with simple implementations of shared / distributed storage. Again, to use the chat system as an illustration, we could have chat participants store chat logs and offer them to new participants who broadcast a request for the last N minutes of conversation. There is a lot of distributed storage work for us to reference, of course, so we have our work cut out for us! Aside f/rom enhancements and features in the messaging system itself, we have plenty of ideas for the actual applications. We have recently been prototyping games that could use a neighborhood or multi-neighborhood mesh network as a playing field. We have found that prototyping and brainstorming games is an enlightening process: it helps explain the ins and outs of the technology to people, and also presents clear challenges to create obvious and attainable goals within the technology’s limitations. We’ll be sharing some “capture the flag” style game ideas that utilize a “meshaging” system during the next couple of weeks.

+

Tags:

+ + messaging  + + detroit  + +
@@ -248,6 +249,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2012/08/23/meshtether-test-release/index.html b/test.commotion/_site/blog/2012/08/23/meshtether-test-release/index.html index 004a9446..f5980ddc 100644 --- a/test.commotion/_site/blog/2012/08/23/meshtether-test-release/index.html +++ b/test.commotion/_site/blog/2012/08/23/meshtether-test-release/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,21 +107,7 @@

MeshTether test release

-
- -

2012-08-23 / Hans-Christoph Steiner

- -

Commotion MeshTether is an Android app that aims to make it possible to connect to OLSR meshes with a single click of a button. It comes configured for the Commotion mesh by default, but can be entirely configured, and can have multiple mesh "profiles" to choose from. There are two information tabs: Links and Info. Links shows all of the first-hop links and Info shows the entire wifi config and olsrd.conf settings. Additionally, you can share/email debug information from the app's menu. Its working pretty well on the Nexus One I'm using for testing. I've also tried the HTC Wildfire, Motorola Droid, and HTC myTouch 3G. The mesh profiles are implemented like this:

-
  • (default) uses the wifi/ip settings from the preferences and the olsrd.conf that is included in the app
  • the rest are scanned from the file system in two places:
    • in the app's app_bin/ folder
    • /mnt/sdcard/MeshTether (i.e. the MeshTether folder on the SD card)
  • the scanner looks in those folders for *.properties files and takes the filename as the profile name (i.e. myprofile.properties will be linked to the "myprofile" item in the profiles menu)
  • if there is also a myprofile.conf next to the myprofile.properties then it will use that as the olsrd.conf. otherwise, it'll use the included olsrd.conf
  • the properties options are:
    ssid=commotionwireless.net
    bssid=02:CA:FF:EE:BA:BE
    channel=5
    ip=172.29.0.0
    ipgenerate=true
    netmask=255.255.0.0
    dns=8.8.8.8
  • all are required, except 'ipgenerate', which marks the 'ip' as the root for the IP generation algorithm. If 'ipgenerate' is unset or not 'true', then the 'ip' is used as is.
-

Here's a test apk: https://guardianproject.info/builds/CommotionMeshTether/2012-08-22/
md5: 176008560f00d8cef65f0e3e781884e1
sha1: b9151fb635185880007411fd49e8ab5b254ad750 Give it a whirl and let us know how it works for you!

-

Tags:

- - nil}">{"categories"=>nil}  - - -
- -
+

Tags:

@@ -226,6 +213,20 @@

Tags:

hack day (1)
+
+ +
+ +

2012-08-23 / Hans-Christoph Steiner

+ +

Commotion MeshTether is an Android app that aims to make it possible to connect to OLSR meshes with a single click of a button. It comes configured for the Commotion mesh by default, but can be entirely configured, and can have multiple mesh "profiles" to choose from. There are two information tabs: Links and Info. Links shows all of the first-hop links and Info shows the entire wifi config and olsrd.conf settings. Additionally, you can share/email debug information from the app's menu. Its working pretty well on the Nexus One I'm using for testing. I've also tried the HTC Wildfire, Motorola Droid, and HTC myTouch 3G. The mesh profiles are implemented like this:

+
  • (default) uses the wifi/ip settings from the preferences and the olsrd.conf that is included in the app
  • the rest are scanned from the file system in two places:
    • in the app's app_bin/ folder
    • /mnt/sdcard/MeshTether (i.e. the MeshTether folder on the SD card)
  • the scanner looks in those folders for *.properties files and takes the filename as the profile name (i.e. myprofile.properties will be linked to the "myprofile" item in the profiles menu)
  • if there is also a myprofile.conf next to the myprofile.properties then it will use that as the olsrd.conf. otherwise, it'll use the included olsrd.conf
  • the properties options are:
    ssid=commotionwireless.net
    bssid=02:CA:FF:EE:BA:BE
    channel=5
    ip=172.29.0.0
    ipgenerate=true
    netmask=255.255.0.0
    dns=8.8.8.8
  • all are required, except 'ipgenerate', which marks the 'ip' as the root for the IP generation algorithm. If 'ipgenerate' is unset or not 'true', then the 'ip' is used as is.
+

Here's a test apk: https://guardianproject.info/builds/CommotionMeshTether/2012-08-22/
md5: 176008560f00d8cef65f0e3e781884e1
sha1: b9151fb635185880007411fd49e8ab5b254ad750 Give it a whirl and let us know how it works for you!

+

Tags:

+ + nil}">{"categories"=>nil}  + +
@@ -248,6 +249,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2012/09/19/making/index.html b/test.commotion/_site/blog/2012/09/19/making/index.html index b3a912a5..996f38b4 100644 --- a/test.commotion/_site/blog/2012/09/19/making/index.html +++ b/test.commotion/_site/blog/2012/09/19/making/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,21 +107,7 @@

The making of...

-
- -

2012-09-19 / The Work Department

- -

This site has been in the making for months and we’re excited to share it with the public! It’s intended to be the online home for the Commotion project — connecting both developers and users to mesh networking tools. We’ve been working with the Open Technology Institute (OTI) and the Commotion community of developers for over a year and this marks a major milestone in our collaborative relationship. Many steps have brought us to this point and many minds have contributed to the process. We’d like to share those key steps with you. Creating the brand identity In May we finished the brand identity for Commotion, which has informed all of our work to date. The versatile and accessible identity (a complete set of logos, typefaces, colors, usage standards, and language) was created for use in multiple environments — online, in print, on mobile phones, and in software. It’s important to us that people experience the Commotion identity consistently, no matter how they are interacting with the project. So, for those of you who have been following Commotion, the look and feel of this website should be no surprise. It adheres well to the brand identity and gives us an opportunity to demonstrate how to implement the identity and expand the visual palette — in a very public and ready-to-use way. Conducting user research We include user research in our planning and design process whenever possible because it’s essential to know what the actual users and surrounding community are thinking. In the early stages of the project, we conducted simple surveys among the Commotion community. Deeper into the process we conducted interviews with four users who were working with neighborhood mesh networks being used as testbeds for Commotion. This research shed some light on how people thought about Commotion, how users actually experienced its early software tools, and what common problems users were facing. This new knowledge informed how we organized the site to speak to two major audiences: developers and end users of the software. Dreaming of user interfaces We spent time prototyping user interfaces and developing Human Interface Guidelines (which are a set of recommendations for developers) with the useful input of many people in the Commotion community. This helped us build a visual framework for Commotion’s user experience and begin to set some standards for how the tools will work across multiple platforms. We established visual languages (descriptive, action, learning, warning, and in-progress languages) that carry through to this website. By interacting with other developers and designers during this “dreaming” stage, we incorporated more ideas and eventually settled on Human Interface Guidelines that meet the community’s needs. Researching other communities There are many successful open-source software projects out there, and it was important to take a look at their structures so we could learn from others and find out what we could improve on. We produced a brief report about four different open-source software communities, which is available here. We compared documentation, support, issue tracking, and governance systems, among others, for each community. This research provided a good overview of what systems were available and widely used. It informed how we structured this site, especially the home page. Drafting designs We started our website design process by creating a sitemap and set of wireframes to outline the navigational structure and content. We went through several iterations (over the course of a few weeks) based on feedback from Commotion developers and OTI staff members. Once this was complete, we began drafting designs for the home page and a few interior pages. We went through a similar revision process with OTI and created several iterations before coming to a final version which is the site you see today. The home page is the primary way in which we invite two different audiences to find what's relevant to them — new visitors and returning visitors. Because Commotion is such a young project and because the public has little experience with mesh networking, we wanted to create an easy introduction to the project while allowing returning visitors to access the main navigation menu. The details This site is run on Drupal and the Omega base theme. It is responsive to browser size (try changing the size of your browser!) and has been built with visual accessibility in mind (with sufficient contrast and without relying on color coding). It makes frequent use of the Context, Media, Panels, Wikitools, and Book modules in Drupal. Using Drupal’s basic role distinctions, different areas of the site will eventually be edited by different teams or staff members as the Commotion community evolves. Team leaders will have access to specific areas of the site that they are responsible for. And, blog submissions are welcomed from anyone working in the Commotion community. In fact, if you have something you’d like to write about, contact us! Thanks to everyone who has been involved in this design process! We look forward to a vibrant online community that helps newcomers try out and understand mesh networking. Please share your feedback about the new site by submitting a comment below.

-

Tags:

- - drupal  - - branding  - - -
- -
+

Tags:

@@ -226,6 +213,20 @@

Tags:

hack day (1)
+
+ +
+ +

2012-09-19 / The Work Department

+ +

This site has been in the making for months and we’re excited to share it with the public! It’s intended to be the online home for the Commotion project — connecting both developers and users to mesh networking tools. We’ve been working with the Open Technology Institute (OTI) and the Commotion community of developers for over a year and this marks a major milestone in our collaborative relationship. Many steps have brought us to this point and many minds have contributed to the process. We’d like to share those key steps with you. Creating the brand identity In May we finished the brand identity for Commotion, which has informed all of our work to date. The versatile and accessible identity (a complete set of logos, typefaces, colors, usage standards, and language) was created for use in multiple environments — online, in print, on mobile phones, and in software. It’s important to us that people experience the Commotion identity consistently, no matter how they are interacting with the project. So, for those of you who have been following Commotion, the look and feel of this website should be no surprise. It adheres well to the brand identity and gives us an opportunity to demonstrate how to implement the identity and expand the visual palette — in a very public and ready-to-use way. Conducting user research We include user research in our planning and design process whenever possible because it’s essential to know what the actual users and surrounding community are thinking. In the early stages of the project, we conducted simple surveys among the Commotion community. Deeper into the process we conducted interviews with four users who were working with neighborhood mesh networks being used as testbeds for Commotion. This research shed some light on how people thought about Commotion, how users actually experienced its early software tools, and what common problems users were facing. This new knowledge informed how we organized the site to speak to two major audiences: developers and end users of the software. Dreaming of user interfaces We spent time prototyping user interfaces and developing Human Interface Guidelines (which are a set of recommendations for developers) with the useful input of many people in the Commotion community. This helped us build a visual framework for Commotion’s user experience and begin to set some standards for how the tools will work across multiple platforms. We established visual languages (descriptive, action, learning, warning, and in-progress languages) that carry through to this website. By interacting with other developers and designers during this “dreaming” stage, we incorporated more ideas and eventually settled on Human Interface Guidelines that meet the community’s needs. Researching other communities There are many successful open-source software projects out there, and it was important to take a look at their structures so we could learn from others and find out what we could improve on. We produced a brief report about four different open-source software communities, which is available here. We compared documentation, support, issue tracking, and governance systems, among others, for each community. This research provided a good overview of what systems were available and widely used. It informed how we structured this site, especially the home page. Drafting designs We started our website design process by creating a sitemap and set of wireframes to outline the navigational structure and content. We went through several iterations (over the course of a few weeks) based on feedback from Commotion developers and OTI staff members. Once this was complete, we began drafting designs for the home page and a few interior pages. We went through a similar revision process with OTI and created several iterations before coming to a final version which is the site you see today. The home page is the primary way in which we invite two different audiences to find what's relevant to them — new visitors and returning visitors. Because Commotion is such a young project and because the public has little experience with mesh networking, we wanted to create an easy introduction to the project while allowing returning visitors to access the main navigation menu. The details This site is run on Drupal and the Omega base theme. It is responsive to browser size (try changing the size of your browser!) and has been built with visual accessibility in mind (with sufficient contrast and without relying on color coding). It makes frequent use of the Context, Media, Panels, Wikitools, and Book modules in Drupal. Using Drupal’s basic role distinctions, different areas of the site will eventually be edited by different teams or staff members as the Commotion community evolves. Team leaders will have access to specific areas of the site that they are responsible for. And, blog submissions are welcomed from anyone working in the Commotion community. In fact, if you have something you’d like to write about, contact us! Thanks to everyone who has been involved in this design process! We look forward to a vibrant online community that helps newcomers try out and understand mesh networking. Please share your feedback about the new site by submitting a comment below.

+

Tags:

+ + drupal  + + branding  + +
@@ -248,6 +249,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2012/10/08/diving-deeper-meshaging/index.html b/test.commotion/_site/blog/2012/10/08/diving-deeper-meshaging/index.html index ebfcb6c1..490e918b 100644 --- a/test.commotion/_site/blog/2012/10/08/diving-deeper-meshaging/index.html +++ b/test.commotion/_site/blog/2012/10/08/diving-deeper-meshaging/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,25 +107,7 @@

Diving deeper into "meshaging"

-
- -

2012-10-08 / The Work Department

- -

In our recent blog post about messaging, we introduced our “meshaging” (basic chat) application and explained some of the plans for our future work with it. We are still working on this project and have diagrammed how exactly communication happens in the application. This has improved our internal process and we think it's beneficial to share. Compared to centralized, server-based systems, decentralized networking applications are a bit messy: with the benefit of decentralization comes the cost of increased complexity. Maintaining consistency of data across a mesh network is a hard problem to solve, and there are plenty of interesting approaches to address this problem. As designers, we became interested in embracing inconsistency: what systems could exist, or even thrive, in a network of inconsistent connections or transient devices? This is important to consider because a mesh network could be constantly changing. To explore the subject of decentralized communication, we decided to work through the design of a mesh network chat application in which nodes would serve as chat hubs. We considered what a decentralized chat application would look like with varying levels of message-sharing or replication between neighbor nodes. We used the analogy of a chat application because of its simplicity and its generality, but you can replace “chats” with any sort of one-to-many message. Actually, as an exercise, you really should try and think of other types of messages that might be transported over a mesh network! Imagine a network of thermometers in a greenhouse, or a network of motion sensors that trigger floodlights, or many other possibilities. Diagram 1 (above) illustrates a chat application in which nodes broadcast messages only to locally connected clients (zero hops). The numbers 1, 2, and 3 represent nodes connected to the mesh network, and the little people icons designated with letters represent the people connected to each of those nodes. In this scenario, users can chat with other users on the same node. For example, Person H can chat with Person J because they are both connected to Node 2. They cannot however chat with Person K or Person D, because those users, though connected to the mesh network, are on different nodes. Diagram 2(above) illustrates users on Node 1 communicating (zero-hop/no-broadcast chat system). Diagram 3 (above) illustrates a next-neighbor broadcast chat system, in which nodes would broadcast all messages to nodes within a one-hop distance. This system would allow a person to chat with people connected to their own node or their next neighbors, but not nodes two or more hops away. In Diagram 3, Person G can chat with Person C because they are both connected to Node 1. But in this stage Person G can also chat with Person J because J is connected to G’s next neighbor, Node 2. Person G could not chat with Person L though, because Node 3, which Person L is connected to, is two hops away. Diagram 4 (above) shows the next-neighbor broadcast chat system, illustrating users on Node 1 communicating with each other and users on Node 2. We hope that these diagrams can help spur conversations about decentralized application development. Stay tuned for more meshages.

-

Tags:

- - messaging  - - chat  - - ux  - - applications  - - -
- -
+

Tags:

@@ -230,6 +213,24 @@

Tags:

hack day (1)
+
+ +
+ +

2012-10-08 / The Work Department

+ +

In our recent blog post about messaging, we introduced our “meshaging” (basic chat) application and explained some of the plans for our future work with it. We are still working on this project and have diagrammed how exactly communication happens in the application. This has improved our internal process and we think it's beneficial to share. Compared to centralized, server-based systems, decentralized networking applications are a bit messy: with the benefit of decentralization comes the cost of increased complexity. Maintaining consistency of data across a mesh network is a hard problem to solve, and there are plenty of interesting approaches to address this problem. As designers, we became interested in embracing inconsistency: what systems could exist, or even thrive, in a network of inconsistent connections or transient devices? This is important to consider because a mesh network could be constantly changing. To explore the subject of decentralized communication, we decided to work through the design of a mesh network chat application in which nodes would serve as chat hubs. We considered what a decentralized chat application would look like with varying levels of message-sharing or replication between neighbor nodes. We used the analogy of a chat application because of its simplicity and its generality, but you can replace “chats” with any sort of one-to-many message. Actually, as an exercise, you really should try and think of other types of messages that might be transported over a mesh network! Imagine a network of thermometers in a greenhouse, or a network of motion sensors that trigger floodlights, or many other possibilities. Diagram 1 (above) illustrates a chat application in which nodes broadcast messages only to locally connected clients (zero hops). The numbers 1, 2, and 3 represent nodes connected to the mesh network, and the little people icons designated with letters represent the people connected to each of those nodes. In this scenario, users can chat with other users on the same node. For example, Person H can chat with Person J because they are both connected to Node 2. They cannot however chat with Person K or Person D, because those users, though connected to the mesh network, are on different nodes. Diagram 2(above) illustrates users on Node 1 communicating (zero-hop/no-broadcast chat system). Diagram 3 (above) illustrates a next-neighbor broadcast chat system, in which nodes would broadcast all messages to nodes within a one-hop distance. This system would allow a person to chat with people connected to their own node or their next neighbors, but not nodes two or more hops away. In Diagram 3, Person G can chat with Person C because they are both connected to Node 1. But in this stage Person G can also chat with Person J because J is connected to G’s next neighbor, Node 2. Person G could not chat with Person L though, because Node 3, which Person L is connected to, is two hops away. Diagram 4 (above) shows the next-neighbor broadcast chat system, illustrating users on Node 1 communicating with each other and users on Node 2. We hope that these diagrams can help spur conversations about decentralized application development. Stay tuned for more meshages.

+

Tags:

+ + messaging  + + chat  + + ux  + + applications  + +
@@ -252,6 +253,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2012/11/01/updating-commotion-package/index.html b/test.commotion/_site/blog/2012/11/01/updating-commotion-package/index.html index 30eed603..ce02ffbb 100644 --- a/test.commotion/_site/blog/2012/11/01/updating-commotion-package/index.html +++ b/test.commotion/_site/blog/2012/11/01/updating-commotion-package/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,62 +107,7 @@

Updating a Commotion package

-
- -

2012-11-01 / The Work Department

- -

In our previous blog post, we walked through the process of creating an OpenWRT package to provide a ws-routing server. We've since continued development on this, and would like to share our process for updating the OpenWRT package after making bugfixes. We'd also like to introduce the commotion-chat package that puts the ws-routing server to use. After we fixed the bug in the ws-routing server code, we needed to update the OpenWRT package to reference the most recent Git revision. Below, you can find a quick guide on how to update an OpenWRT package. First, you need to update the Git revision. Do this by editing the package's Makefile and changing a variable:

- -
cd commotion-examples/ws-routing # get in the package
-vim Makefile # edit the makefile, increment PKG_RELEASE, and update the PKG_REV to the latest commit&#39;s hash
-# e.g.
-#PKG_RELEASE:=2
-#PKG_REV:=7942da7b7ed4afc4c42b28553b0baf3a47060917
-cd ..
-# rerun the setup for this package
-./setup.sh
-cd ../commotion-openwrt/openwrt
-# if you haven&#39;t built the OpenWRT base system yet, you can run &quot;make&quot; to build everything
-make package/ws-routing/install
-cd bin/ar71xx/packages
-python -m SimpleHTTPServer 8080 # start a webserver so your openwrt router can download the new package
-# if you don&#39;t have python installed, you can pursue other means of installing the package :)
- -

After completing the steps above, open your web browser and navigate to http://<your_ip>:8080/, substituting your computer's IP address. Copy this URL for the ws-routing package. Now, open another browser tab and connect to your OpenWRT router's administrative interface. Go to "Administration," hover over "System," click "Software," and paste in the URL of the ws-routing package in the "Download and install package" form. (TIP: If an older version of the package is already installed, you may want to remove it before reinstalling.) Before it installs, you'll need to click "OK." You'll see a message that the package was downloaded & upgraded.

-

The Fun Part

-

Now that we've updated and installed this mysterious package, let's put it to use. The commotion-chat package installs some HTML and Javascript that is made available through a new menu route in the LuCI interface. The chat app itself is rough and purely for experimentation and fun — please don't use this in a production community wireless environment. Only use it for fun, and experimentation. Download and install the commotion-chat package alongside your commotion-openwrt tree:

- -
# if you&#39;re currently in commotion-openwrt/openwrt...
-cd ../../ 
-# clone commotion-chat feed 
-git clone https://github.com/bnchdrff/commotion-chat.git 
-cd commotion-chat 
-./setup.sh 
-cd ../commotion-openwrt/openwrt 
-make menuconfig 
-# select the commotion-chat package under commotion apps for installation 
-# if you haven&#39;t built the OpenWRT base system yet, you can run &quot;make&quot; to build everything 
-make package/commotionchat/install 
-cd bin/ar71xx/packages 
-# start a webserver so your openwrt router can download the new package 
-python -m SimpleHTTPServer 8080 
-# if you don&#39;t have python installed, you can pursue other means of installing the package :)
- -

Then, follow the same workflow described above for the ws-routing package to install commotion-chat on your router. After installing these packages, you may need to reboot the router. Hover over "System," and click "Reboot." Confirm, wait a few minutes, and then try visiting your router's splash page. If you installed/updated commotion-ws-routing and commotion-chat successfully, you can now click on the "Chat" menu item under "Applications" and try out the chat app!

-

Tags:

- - chat  - - applications  - - routers  - - messaging  - - -
- -
+

Tags:

@@ -267,6 +213,61 @@

Tags:

hack day (1)
+
+ +
+ +

2012-11-01 / The Work Department

+ +

In our previous blog post, we walked through the process of creating an OpenWRT package to provide a ws-routing server. We've since continued development on this, and would like to share our process for updating the OpenWRT package after making bugfixes. We'd also like to introduce the commotion-chat package that puts the ws-routing server to use. After we fixed the bug in the ws-routing server code, we needed to update the OpenWRT package to reference the most recent Git revision. Below, you can find a quick guide on how to update an OpenWRT package. First, you need to update the Git revision. Do this by editing the package's Makefile and changing a variable:

+ +
cd commotion-examples/ws-routing # get in the package
+vim Makefile # edit the makefile, increment PKG_RELEASE, and update the PKG_REV to the latest commit&#39;s hash
+# e.g.
+#PKG_RELEASE:=2
+#PKG_REV:=7942da7b7ed4afc4c42b28553b0baf3a47060917
+cd ..
+# rerun the setup for this package
+./setup.sh
+cd ../commotion-openwrt/openwrt
+# if you haven&#39;t built the OpenWRT base system yet, you can run &quot;make&quot; to build everything
+make package/ws-routing/install
+cd bin/ar71xx/packages
+python -m SimpleHTTPServer 8080 # start a webserver so your openwrt router can download the new package
+# if you don&#39;t have python installed, you can pursue other means of installing the package :)
+ +

After completing the steps above, open your web browser and navigate to http://<your_ip>:8080/, substituting your computer's IP address. Copy this URL for the ws-routing package. Now, open another browser tab and connect to your OpenWRT router's administrative interface. Go to "Administration," hover over "System," click "Software," and paste in the URL of the ws-routing package in the "Download and install package" form. (TIP: If an older version of the package is already installed, you may want to remove it before reinstalling.) Before it installs, you'll need to click "OK." You'll see a message that the package was downloaded & upgraded.

+

The Fun Part

+

Now that we've updated and installed this mysterious package, let's put it to use. The commotion-chat package installs some HTML and Javascript that is made available through a new menu route in the LuCI interface. The chat app itself is rough and purely for experimentation and fun — please don't use this in a production community wireless environment. Only use it for fun, and experimentation. Download and install the commotion-chat package alongside your commotion-openwrt tree:

+ +
# if you&#39;re currently in commotion-openwrt/openwrt...
+cd ../../ 
+# clone commotion-chat feed 
+git clone https://github.com/bnchdrff/commotion-chat.git 
+cd commotion-chat 
+./setup.sh 
+cd ../commotion-openwrt/openwrt 
+make menuconfig 
+# select the commotion-chat package under commotion apps for installation 
+# if you haven&#39;t built the OpenWRT base system yet, you can run &quot;make&quot; to build everything 
+make package/commotionchat/install 
+cd bin/ar71xx/packages 
+# start a webserver so your openwrt router can download the new package 
+python -m SimpleHTTPServer 8080 
+# if you don&#39;t have python installed, you can pursue other means of installing the package :)
+ +

Then, follow the same workflow described above for the ws-routing package to install commotion-chat on your router. After installing these packages, you may need to reboot the router. Hover over "System," and click "Reboot." Confirm, wait a few minutes, and then try visiting your router's splash page. If you installed/updated commotion-ws-routing and commotion-chat successfully, you can now click on the "Chat" menu item under "Applications" and try out the chat app!

+

Tags:

+ + chat  + + applications  + + routers  + + messaging  + +
@@ -289,6 +290,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2012/11/06/brainstorming-how-neighborhood-power-grids-could-work-community-mesh-networks/index.html b/test.commotion/_site/blog/2012/11/06/brainstorming-how-neighborhood-power-grids-could-work-community-mesh-networks/index.html index b04c3cbb..b1ca11b6 100644 --- a/test.commotion/_site/blog/2012/11/06/brainstorming-how-neighborhood-power-grids-could-work-community-mesh-networks/index.html +++ b/test.commotion/_site/blog/2012/11/06/brainstorming-how-neighborhood-power-grids-could-work-community-mesh-networks/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,23 +107,7 @@

Brainstorming how neighborhood power grids could work w
-
- -

2012-11-06 / The Work Department

- -

A community wireless network can provide a reliable conduit for many types of communication. We might initially think of this communication within a human context — sharing music with your friend across town, spreading news to your city about an upcoming event, responding to an emergency, or asking questions of a local politician on a discussion forum. But, in a world that runs parallel to the Internet we use everyday, our communication networks are used by all sorts of machines to make our society an exponentially more productive and automated place. These “robots” in our communities, all of those appliances and devices with embedded computers, could also benefit from a community mesh network. Moving into the future, we’ll be inspired to redesign some of these helpful robots and algorithms to be more decentralized and useful on hyperlocal levels. In Detroit, we’re thinking more about what role a community wireless network could play in organizing automated communication to better sustain our human neighborhoods and communities. For example, a house produces a never-ending stream of usage data ranging from kilowatt-hours of electricity to gallons of water to cubic-feet of gas. Hobbyists have taken an interest in this data, especially electrical usage. The current trend of home energy information technology is inspirational yet clearly missing some components that would increase democratic control. Energy companies have certainly accumulated a wealth of innovative and efficient systems for large-scale electricity distribution, but what if we came up with simple systems that enable neighbors to easily share power grid information over a community wireless network? Here, we enter the realm of local energy sharing and distribution built on locally owned and controlled data systems. Beyond the benefits of each home knowing its impact on the energy use of the community, this distributed monitoring could be useful to people who use alternative energy sources like wind or solar power. These energy systems require a charge controller and other electronics which often have data sharing systems or APIs similar to usage monitors. This software could use community wireless networks to manage energy sharing. For example, a house with solar panels could share energy with its neighbor with wind turbines on sunny days, and the neighbor with wind turbines could share energy with the solar house on windy days. On days that are both windy and sunny, both houses could contribute to a shared pool of batteries or donate the excess power to local community services at no cost to themselves. Household energy usage data could be aggregated within applications like Tidepools so community members could compare location-specific energy consumption. And, because of the self-healing nature of mesh networks, these energy-sharing systems could be more resilient during times of disaster or failing infrastructure. In Detroit, the team at The Work Department has also been brainstorming with two community projects: Power House Productions and Mt. Elliott Makerspace. Whether through youth workshops or architectural installations, these groups work to introduce people to alternative energy and neighborhood-level systems — concepts that can be related to community wireless networks. We're also keeping tabs on an exciting project called the “Solar Pocket Factory” because small-scale solar technology could play a crucial role in letting a delay-tolerant mesh network scale. As our conversations progress, we’ll post more notes on this blog.

-

Tags:

- - community wireless  - - energy  - - detroit  - - -
- -
+

Tags:

@@ -228,6 +213,22 @@

Tags:

hack day (1)
+
+ +
+ +

2012-11-06 / The Work Department

+ +

A community wireless network can provide a reliable conduit for many types of communication. We might initially think of this communication within a human context — sharing music with your friend across town, spreading news to your city about an upcoming event, responding to an emergency, or asking questions of a local politician on a discussion forum. But, in a world that runs parallel to the Internet we use everyday, our communication networks are used by all sorts of machines to make our society an exponentially more productive and automated place. These “robots” in our communities, all of those appliances and devices with embedded computers, could also benefit from a community mesh network. Moving into the future, we’ll be inspired to redesign some of these helpful robots and algorithms to be more decentralized and useful on hyperlocal levels. In Detroit, we’re thinking more about what role a community wireless network could play in organizing automated communication to better sustain our human neighborhoods and communities. For example, a house produces a never-ending stream of usage data ranging from kilowatt-hours of electricity to gallons of water to cubic-feet of gas. Hobbyists have taken an interest in this data, especially electrical usage. The current trend of home energy information technology is inspirational yet clearly missing some components that would increase democratic control. Energy companies have certainly accumulated a wealth of innovative and efficient systems for large-scale electricity distribution, but what if we came up with simple systems that enable neighbors to easily share power grid information over a community wireless network? Here, we enter the realm of local energy sharing and distribution built on locally owned and controlled data systems. Beyond the benefits of each home knowing its impact on the energy use of the community, this distributed monitoring could be useful to people who use alternative energy sources like wind or solar power. These energy systems require a charge controller and other electronics which often have data sharing systems or APIs similar to usage monitors. This software could use community wireless networks to manage energy sharing. For example, a house with solar panels could share energy with its neighbor with wind turbines on sunny days, and the neighbor with wind turbines could share energy with the solar house on windy days. On days that are both windy and sunny, both houses could contribute to a shared pool of batteries or donate the excess power to local community services at no cost to themselves. Household energy usage data could be aggregated within applications like Tidepools so community members could compare location-specific energy consumption. And, because of the self-healing nature of mesh networks, these energy-sharing systems could be more resilient during times of disaster or failing infrastructure. In Detroit, the team at The Work Department has also been brainstorming with two community projects: Power House Productions and Mt. Elliott Makerspace. Whether through youth workshops or architectural installations, these groups work to introduce people to alternative energy and neighborhood-level systems — concepts that can be related to community wireless networks. We're also keeping tabs on an exciting project called the “Solar Pocket Factory” because small-scale solar technology could play a crucial role in letting a delay-tolerant mesh network scale. As our conversations progress, we’ll post more notes on this blog.

+

Tags:

+ + community wireless  + + energy  + + detroit  + +
@@ -250,6 +251,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2012/11/14/cost-mesh-networks/index.html b/test.commotion/_site/blog/2012/11/14/cost-mesh-networks/index.html index 7638bce9..9e544ea8 100644 --- a/test.commotion/_site/blog/2012/11/14/cost-mesh-networks/index.html +++ b/test.commotion/_site/blog/2012/11/14/cost-mesh-networks/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,25 +107,7 @@

The Cost of Mesh Networks

-
- -

2012-11-14 / s2e

- - -

Tags:

- - mesh  - - cost  - - price  - - hardware  - - -
- -
+

Tags:

@@ -230,6 +213,24 @@

Tags:

hack day (1)
+
+ +
+ +

2012-11-14 / s2e

+ + +

Tags:

+ + mesh  + + cost  + + price  + + hardware  + +
@@ -252,6 +253,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2012/11/20/commotion-and-declaration-internet-freedom/index.html b/test.commotion/_site/blog/2012/11/20/commotion-and-declaration-internet-freedom/index.html index 716b1208..b15d23a7 100644 --- a/test.commotion/_site/blog/2012/11/20/commotion-and-declaration-internet-freedom/index.html +++ b/test.commotion/_site/blog/2012/11/20/commotion-and-declaration-internet-freedom/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,34 +107,7 @@

Commotion and the Declaration of Internet Freedom

-
- -

2012-11-20 / OTI

- -

Over the past few decades, networks have become as important as borders, strategies of inclusion as vital as policies of coercion, and governments everywhere are struggling with the fact that increased participation means relinquished control. The Declaration of Internet Freedom, written during the summer of 2012, comes at an important tipping point. Across the world, citizen expectations to participate in building a common future have outpaced governments’ ability to provide this shared destiny. Global dynamics are dramatically shifting. Nations the world over face a common dilemma: our top-down governance structures are incapable of building the kind of widespread social resilience that modern self-determination requires. The rise of a networked globe means that civil society—organizations and individuals outside of formal government—will play an increasingly powerful role in determining the future. The Declaration of Internet Freedom intends to help guide and bolster this important change. The Commotion project aims to create a free and open Internet, supporting the goals of the Declaration both in spirit and in practice. Commotion is an open source communication tool that uses common devices to create distributed, mesh networks. Commotion embodies the five Declaration principles in the following ways:

-
  • **“Expression: Don't censor the Internet”** -
-

Commotion is a distributed system that aims to prevent ease of monitoring and censorship that is enabled by the centralized nature of conventional communications infrastructure. The need for this kind of dis-aggregated capacity to connect has been evident during the ongoing uprisings of the Middle East and North Africa. With Commotion, there is no possibility for a single power switch for use by a dictator that are increasing being seen on centralized systems around the world.

-
  • **“Access: Promote universal access to fast and affordable networks”** -
-

Commotion will be available to individuals using a wide range of technical devices—including mobile phones. The mesh system is decentralized and readily extensible which makes it inclusive by its very structure.

-
  • **“Openness: Keep the Internet an open network where everyone is free to connect, communicate, write, read, watch, speak, listen, learn, create and innovate.”** -
-

The freedom of humans to communicate is the paramount belief and motivation behind Commotion. The open source nature of the Commotion project also emphasizes our commitment to this principle in Commotion's creation and by freeing the code for innovation.

-
  • **“Innovation: Protect the freedom to innovate and create without permission. Don’t block new technologies and don’t punish innovators for their users' actions.”** -
-

The world’s future depends on shared prosperity, which will require a default to openness and innovation at every level of human interaction. Commotion aims to create an open local network which innovators can extend and build upon to create novel applications that serve the needs of their communities.

-
  • **“Privacy: Protect privacy and defend everyone’s ability to control how their data and devices are used”** -
-

Commotion is a global alliance of individuals and organizations, some of whom are exclusively dedicated to individual privacy and the prevention of unwanted intrusion and surveillance. A global capacity to prosper and to live a safe life may seem like an overwhelming ambition. Yet never before has humankind owned the tools that will allow us to immediately call upon each other for support to persevere through challenges, to adapt, change and grow. Our individual destinies are wrapped up in the destiny of life across the globe—the communications revolution has collapsed time and space, and has created both mayhem and empathy. The Commotion project intends to put in place an infrastructure that will democratize today’s communication. As governments struggle with a world where power is being rapidly redistributed out of formal institutions and into the hands of people, the developers of Commotion intend to work with other like minds who, together, will take these ingredients and help discover the alchemy of modern democracy.

-

Tags:

- - nil}">{"categories"=>nil}  - - -
- -
+

Tags:

@@ -239,6 +213,33 @@

Tags:

hack day (1)
+
+ +
+ +

2012-11-20 / OTI

+ +

Over the past few decades, networks have become as important as borders, strategies of inclusion as vital as policies of coercion, and governments everywhere are struggling with the fact that increased participation means relinquished control. The Declaration of Internet Freedom, written during the summer of 2012, comes at an important tipping point. Across the world, citizen expectations to participate in building a common future have outpaced governments’ ability to provide this shared destiny. Global dynamics are dramatically shifting. Nations the world over face a common dilemma: our top-down governance structures are incapable of building the kind of widespread social resilience that modern self-determination requires. The rise of a networked globe means that civil society—organizations and individuals outside of formal government—will play an increasingly powerful role in determining the future. The Declaration of Internet Freedom intends to help guide and bolster this important change. The Commotion project aims to create a free and open Internet, supporting the goals of the Declaration both in spirit and in practice. Commotion is an open source communication tool that uses common devices to create distributed, mesh networks. Commotion embodies the five Declaration principles in the following ways:

+
  • **“Expression: Don't censor the Internet”** +
+

Commotion is a distributed system that aims to prevent ease of monitoring and censorship that is enabled by the centralized nature of conventional communications infrastructure. The need for this kind of dis-aggregated capacity to connect has been evident during the ongoing uprisings of the Middle East and North Africa. With Commotion, there is no possibility for a single power switch for use by a dictator that are increasing being seen on centralized systems around the world.

+
  • **“Access: Promote universal access to fast and affordable networks”** +
+

Commotion will be available to individuals using a wide range of technical devices—including mobile phones. The mesh system is decentralized and readily extensible which makes it inclusive by its very structure.

+
  • **“Openness: Keep the Internet an open network where everyone is free to connect, communicate, write, read, watch, speak, listen, learn, create and innovate.”** +
+

The freedom of humans to communicate is the paramount belief and motivation behind Commotion. The open source nature of the Commotion project also emphasizes our commitment to this principle in Commotion's creation and by freeing the code for innovation.

+
  • **“Innovation: Protect the freedom to innovate and create without permission. Don’t block new technologies and don’t punish innovators for their users' actions.”** +
+

The world’s future depends on shared prosperity, which will require a default to openness and innovation at every level of human interaction. Commotion aims to create an open local network which innovators can extend and build upon to create novel applications that serve the needs of their communities.

+
  • **“Privacy: Protect privacy and defend everyone’s ability to control how their data and devices are used”** +
+

Commotion is a global alliance of individuals and organizations, some of whom are exclusively dedicated to individual privacy and the prevention of unwanted intrusion and surveillance. A global capacity to prosper and to live a safe life may seem like an overwhelming ambition. Yet never before has humankind owned the tools that will allow us to immediately call upon each other for support to persevere through challenges, to adapt, change and grow. Our individual destinies are wrapped up in the destiny of life across the globe—the communications revolution has collapsed time and space, and has created both mayhem and empathy. The Commotion project intends to put in place an infrastructure that will democratize today’s communication. As governments struggle with a world where power is being rapidly redistributed out of formal institutions and into the hands of people, the developers of Commotion intend to work with other like minds who, together, will take these ingredients and help discover the alchemy of modern democracy.

+

Tags:

+ + nil}">{"categories"=>nil}  + +
@@ -261,6 +262,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2013/02/02/case-study-red-hook-initiative-wifi-tidepools/index.html b/test.commotion/_site/blog/2013/02/02/case-study-red-hook-initiative-wifi-tidepools/index.html index 54f21780..e8f282fa 100644 --- a/test.commotion/_site/blog/2013/02/02/case-study-red-hook-initiative-wifi-tidepools/index.html +++ b/test.commotion/_site/blog/2013/02/02/case-study-red-hook-initiative-wifi-tidepools/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,31 +107,7 @@

Case Study - Red Hook Initiative WiFi & Tidepools

-
- -

2013-02-02 / georgia

- - -

Tags:

- - red hook  - - hardware  - - cost  - - community wireless  - - applications  - - research  - - mesh  - - -
- -
+

Tags:

@@ -236,6 +213,30 @@

Tags:

hack day (1)
+
+ +
+ +

2013-02-02 / georgia

+ + +

Tags:

+ + red hook  + + hardware  + + cost  + + community wireless  + + applications  + + research  + + mesh  + +
@@ -258,6 +259,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2013/02/25/troubleshooting-wireless-network-technical-physical-and-social-needs/index.html b/test.commotion/_site/blog/2013/02/25/troubleshooting-wireless-network-technical-physical-and-social-needs/index.html index 9d7c4284..6c81b3f6 100644 --- a/test.commotion/_site/blog/2013/02/25/troubleshooting-wireless-network-technical-physical-and-social-needs/index.html +++ b/test.commotion/_site/blog/2013/02/25/troubleshooting-wireless-network-technical-physical-and-social-needs/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,31 +107,7 @@

Troubleshooting a Wireless Network - Technical, Physica
-
- -

2013-02-25 / georgia

- - -

Tags:

- - red hook  - - hardware  - - community wireless  - - mesh  - - troubleshooting  - - site visits  - - maintenance  - - -
- -
+

Tags:

@@ -236,6 +213,30 @@

Tags:

hack day (1)
+
+ +
+ +

2013-02-25 / georgia

+ + +

Tags:

+ + red hook  + + hardware  + + community wireless  + + mesh  + + troubleshooting  + + site visits  + + maintenance  + +
@@ -258,6 +259,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2013/02/25/warning-label-development-part-1/index.html b/test.commotion/_site/blog/2013/02/25/warning-label-development-part-1/index.html index a8e9f934..fde86f55 100644 --- a/test.commotion/_site/blog/2013/02/25/warning-label-development-part-1/index.html +++ b/test.commotion/_site/blog/2013/02/25/warning-label-development-part-1/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,55 +107,7 @@

Warning Label Development, Part 1

-
- -

2013-02-25 / OTI

- -

Commotion is not currently a secure circumvention tool. At some point that statement will not be true, but until then this fact must be known by anyone who interacts with Commotion. With the increasing popularity of digital circumvention tools, news outlets have pointed to Commotion as a possible tool for creating safe local communication networks when the usual channels are compromised. When an unfinished project like Commotion enters the spotlight, it is important to warn potential users about the limitations of the tools in development. In the circumvention and cryptography communities, this is usually done with a warning. This post will walk through our process for developing a warning label. We hope it will help new projects who face this same dilemma. We decided to frame our search for a warning by asking two questions. What information is important for a potential user of Commotion to have to make an informed decision? How do we ensure the "ability of the individual reading [the warning] to understand the information sufficiently to take the desired action"[1] for their specific situation? We brainstormed country-specific warnings that identified local threats from internet rights watchdogs[2] to create customized warnings for various levels of threat. But with location anonymizing tools[3] and individual variability in threats, we decided to create a unified warning that focuses on what Commotion can't do. Broadly, Commotion is a tool-kit that allows wireless routers, laptop and desktop computers, rooted android phones, and software-defined cell phone basestations to find and communicate with and through each other. What Commotion is unable to do is a trickier question. Commotion is unable to do many things. It cannot ride a bike or do my taxes. But, most users will not expect these things. In order to tell potential users what Commotion cannot do, we needed to find out the potential set of functionality users expect of Commotion. To discover possible expectations, we poured over our own outreach and the press we have received to see what it conveyed to those who read it. Here is a collection of salient snippets, and what functionality we gleaned from them. Secure independent wireless for conflicts and disasters:

-
"\[The\] Internet in a Suitcase is basically a software program aimed at giving people in conflict or disaster zones the ability to establish a secure, independent wireless network over their computers and cell phones." \[4\]
-

Device and centralized infrastructure-independent tool which eliminates surveillance and monitoring while ensuring the identity of those you communicate with:

-
"This is a completely ad hoc network, there's no dependency of any device on any other device and that eliminates a central point for command and control surveillance and monitoring," said Meinrath. "We also have authentication between each hop on the network and encryption across each hop." \[4\]
-

Free phone calls:

-
"The killer app that I talk with a lot of folks about is, if you have a system like this, there's no reason you would ever need to pay for local phone calls again" once you've downloaded the software allowing your device to join the wifi network, "because you're just pinging machine to machine over a local network," said Meinrath. \[4\]
-

Cheap tech for routers and Android phones for dissidents to evade censorship:

-
"He and a team of software engineers are developing open-source software to turn cheap wireless access points and Android smartphones into nodes on the network, which could then be used by dissidents to evade censorship and to spread low-cost connections everywhere around the world." \[6\]
-

Easy to install and set up:

-
”The firmware provides auto-configuration capabilities,” said Brian Duggan, one of the engineers on the Internet in a Suitcase project, “so you don’t need to be an engineer” to install it. “You flash as many nodes as you want, or pick up previous ones.” \[6\]
-

Delay tolerant access to the Internet:

-
“You could have a delay-tolerant Twitter, where people on the local network could see your tweets and then when a connection is restored it could get pushed to the internet,” Meinrath said. “We are in the very infancy of this kind of intranet.” \[6\]
-

We're rock stars (totally true):

-
"One operation out of a spy novel in a fifth-floor shop on L Street in Washington, where a group of young entrepreneurs who look as if they could be in a garage band are fitting deceptively innocent-looking hardware into a prototype “Internet in a suitcase.” \[5\]
-

Separate from existing infrastructure, impossible to shut down, control, and surveil:

-
“We’re going to build a separate infrastructure where the technology is nearly impossible to shut down, to control, to surveil.” \[5\]
-

Decentralized network using phones, computers:

-
"Commotion is an open-source communication tool that uses mobile phones, computers, and other wireless devices to create decentralized mesh networks." \[7\]
-

Share the internet:

-
"Commotion software also allows users on a mesh network to share access to the Internet. The software does not provide Internet access, but it does allow multiple devices to share their connections." \[7\]
-

Robust network that ensures anonymity and circumvents censorship even when other communication systems have failed:

-
"Commotion is a flexible set of tools that can work well in many different scenarios. They can grow, shrink, and move as necessary and according to available resources. Commotion is organized and maintained by community members to fit their needs. It can act as a backbone for last-mile infrastructure, a local community network, a circumvention and anonymity ensuring communication channel, or a local emergency communications infrastructure when existing systems are severed." \[7\]
-

This set of quotes gave us an idea of what we have presented as the current and future states of Commotion, and therefore, what users may expect from Commotion when they go to download it. We took these quotes and compiled a list of what the current release of Commotion is NOT yet able to do. Commotion does not:

-
  • Provide anonymity
  • Provide delay tolerant communications
  • Prevent monitoring of your internet use
  • Allow you to call to non-Commotion enabled phones
  • Provide a simple user interface for installation or customization
  • Prevent monitoring of Commotion mesh communication
  • Prevent jamming/DoS attacks against a Commotion mesh
  • Provide access without power
  • Provide strong encryption
  • Provide protection from malware on devices
-

With this list in hand we narrowed down to the points that increase the ability of a potential user to make an informed decision about their security. Commotion does not:

-
  • Provide anonymity
  • Prevent monitoring of internet traffic
  • Provide strong security over the mesh
  • Resist jamming or DDoS attacks
  • Protect your device from Malware
-

In Part 2, we'll go over how we used this list of unimplemented security features to develop a warning label.

-

Tags:

- - warning  - - label  - - security  - - anonymity  - - privacy  - - research  - - -
- -
+

Tags:

@@ -260,6 +213,54 @@

Tags:

hack day (1)
+
+ +
+ +

2013-02-25 / OTI

+ +

Commotion is not currently a secure circumvention tool. At some point that statement will not be true, but until then this fact must be known by anyone who interacts with Commotion. With the increasing popularity of digital circumvention tools, news outlets have pointed to Commotion as a possible tool for creating safe local communication networks when the usual channels are compromised. When an unfinished project like Commotion enters the spotlight, it is important to warn potential users about the limitations of the tools in development. In the circumvention and cryptography communities, this is usually done with a warning. This post will walk through our process for developing a warning label. We hope it will help new projects who face this same dilemma. We decided to frame our search for a warning by asking two questions. What information is important for a potential user of Commotion to have to make an informed decision? How do we ensure the "ability of the individual reading [the warning] to understand the information sufficiently to take the desired action"[1] for their specific situation? We brainstormed country-specific warnings that identified local threats from internet rights watchdogs[2] to create customized warnings for various levels of threat. But with location anonymizing tools[3] and individual variability in threats, we decided to create a unified warning that focuses on what Commotion can't do. Broadly, Commotion is a tool-kit that allows wireless routers, laptop and desktop computers, rooted android phones, and software-defined cell phone basestations to find and communicate with and through each other. What Commotion is unable to do is a trickier question. Commotion is unable to do many things. It cannot ride a bike or do my taxes. But, most users will not expect these things. In order to tell potential users what Commotion cannot do, we needed to find out the potential set of functionality users expect of Commotion. To discover possible expectations, we poured over our own outreach and the press we have received to see what it conveyed to those who read it. Here is a collection of salient snippets, and what functionality we gleaned from them. Secure independent wireless for conflicts and disasters:

+
"\[The\] Internet in a Suitcase is basically a software program aimed at giving people in conflict or disaster zones the ability to establish a secure, independent wireless network over their computers and cell phones." \[4\]
+

Device and centralized infrastructure-independent tool which eliminates surveillance and monitoring while ensuring the identity of those you communicate with:

+
"This is a completely ad hoc network, there's no dependency of any device on any other device and that eliminates a central point for command and control surveillance and monitoring," said Meinrath. "We also have authentication between each hop on the network and encryption across each hop." \[4\]
+

Free phone calls:

+
"The killer app that I talk with a lot of folks about is, if you have a system like this, there's no reason you would ever need to pay for local phone calls again" once you've downloaded the software allowing your device to join the wifi network, "because you're just pinging machine to machine over a local network," said Meinrath. \[4\]
+

Cheap tech for routers and Android phones for dissidents to evade censorship:

+
"He and a team of software engineers are developing open-source software to turn cheap wireless access points and Android smartphones into nodes on the network, which could then be used by dissidents to evade censorship and to spread low-cost connections everywhere around the world." \[6\]
+

Easy to install and set up:

+
”The firmware provides auto-configuration capabilities,” said Brian Duggan, one of the engineers on the Internet in a Suitcase project, “so you don’t need to be an engineer” to install it. “You flash as many nodes as you want, or pick up previous ones.” \[6\]
+

Delay tolerant access to the Internet:

+
“You could have a delay-tolerant Twitter, where people on the local network could see your tweets and then when a connection is restored it could get pushed to the internet,” Meinrath said. “We are in the very infancy of this kind of intranet.” \[6\]
+

We're rock stars (totally true):

+
"One operation out of a spy novel in a fifth-floor shop on L Street in Washington, where a group of young entrepreneurs who look as if they could be in a garage band are fitting deceptively innocent-looking hardware into a prototype “Internet in a suitcase.” \[5\]
+

Separate from existing infrastructure, impossible to shut down, control, and surveil:

+
“We’re going to build a separate infrastructure where the technology is nearly impossible to shut down, to control, to surveil.” \[5\]
+

Decentralized network using phones, computers:

+
"Commotion is an open-source communication tool that uses mobile phones, computers, and other wireless devices to create decentralized mesh networks." \[7\]
+

Share the internet:

+
"Commotion software also allows users on a mesh network to share access to the Internet. The software does not provide Internet access, but it does allow multiple devices to share their connections." \[7\]
+

Robust network that ensures anonymity and circumvents censorship even when other communication systems have failed:

+
"Commotion is a flexible set of tools that can work well in many different scenarios. They can grow, shrink, and move as necessary and according to available resources. Commotion is organized and maintained by community members to fit their needs. It can act as a backbone for last-mile infrastructure, a local community network, a circumvention and anonymity ensuring communication channel, or a local emergency communications infrastructure when existing systems are severed." \[7\]
+

This set of quotes gave us an idea of what we have presented as the current and future states of Commotion, and therefore, what users may expect from Commotion when they go to download it. We took these quotes and compiled a list of what the current release of Commotion is NOT yet able to do. Commotion does not:

+
  • Provide anonymity
  • Provide delay tolerant communications
  • Prevent monitoring of your internet use
  • Allow you to call to non-Commotion enabled phones
  • Provide a simple user interface for installation or customization
  • Prevent monitoring of Commotion mesh communication
  • Prevent jamming/DoS attacks against a Commotion mesh
  • Provide access without power
  • Provide strong encryption
  • Provide protection from malware on devices
+

With this list in hand we narrowed down to the points that increase the ability of a potential user to make an informed decision about their security. Commotion does not:

+
  • Provide anonymity
  • Prevent monitoring of internet traffic
  • Provide strong security over the mesh
  • Resist jamming or DDoS attacks
  • Protect your device from Malware
+

In Part 2, we'll go over how we used this list of unimplemented security features to develop a warning label.

+

Tags:

+ + warning  + + label  + + security  + + anonymity  + + privacy  + + research  + +
@@ -282,6 +283,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2013/02/25/warning-label-development-part-2/index.html b/test.commotion/_site/blog/2013/02/25/warning-label-development-part-2/index.html index 4e544ea3..6b5d6db4 100644 --- a/test.commotion/_site/blog/2013/02/25/warning-label-development-part-2/index.html +++ b/test.commotion/_site/blog/2013/02/25/warning-label-development-part-2/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,36 +107,7 @@

Warning Label Development, Part 2

-
- -

2013-02-25 / OTI

- -

In Part 1, we came up with a list of security features Commotion lacked. We took this list of unimplemented security features and used OSHA's hazard communication guide to clarify our language[9]:

-
  • Instructions are more likely to be followed if consequences are described.
  • Sentences that include a long string of effects or other items can be made clearer by putting them into list.
  • Keep sentences short and direct. Use no more than two subordinate clauses. Use the active voice as much as possible. Use short words of one or two syllables as much as possible. Choose commonly used, familiar words, but avoid colloquialisms and slang.
  • Use only common abbreviations and acronyms, and then give their definition as soon after their first use as possible. Occasionally, however, an abbreviation or acronym may be so familiar to intended audiences that it may be used without a definition. In fact, some may be more familiar than the full name (e.g., OSHA, EPA, SARA, F, C, TLV, and TWA)
-

Our first change was to move the negative “does not” that is stated in the header into each statement. This ensures that each statement can be read out of context of the whole with full meaning intact and gave us greater freedom in our wording on each line. We then switched the focus from attacks that Commotion does not protect against to consequences that come from lack of feature sets. For example, we removed "malware" in favor of highlighting the result of data and identity insecurity. We then went through each statement to remove jargon/acronyms and make the language more active. WARNING!Commotion:

-
  • Cannot hide your identity
  • Does not prevent monitoring of internet traffic
  • Does not provide strong security against monitoring over the mesh
  • Can be jammed with radio/data-interference
-

In accordance to ANZI "Product Safety Signs and Labels" [10], the term "warning indicates a potentially hazardous situation which, if not avoided, could result in death or serious injury." We felt that this was appropriate for the current non-secure release of Commotion. The next highest level, "danger" is "to be limited to the most extreme situations." We will reserve this warning for our future release of a "secure" Commotion distribution to emphasize the ways in which it does not provide full security. We hope this escalation will signal to users of Commotion for secure communication that they put themselves in danger by assuming security where it does not exist. In the future, as we have translation done on our documentation, we will also work with translators to ensure that region-specific translations are not direct translations, but instead clearly convey the warnings to the users in the most understandable way. With our language solidified, we started on our second question: How do we ensure the "ability of the individual reading [the warning] to understand the information sufficiently to take the desired action"[1] for their specific situation? The first thing that we did was look for existing literature on warning labels in software, which was sorely lacking. So, we turned to warning labels on tobacco, drugs, and dangerous machinery. "A review of the science base to support the development of health warnings for tobacco packages" is an interesting read for its own merit, and was a great resource in helping us ensure that the warning was in the best possible site placement to reach our users.

-
  1. ...shoppers typically start at the dominant visual element (often the brand name), and are then drawn to the next strongest element (usually the next most dominant visual element).
  2. A related and important point is that viewing patterns are driven by packaging layout rather than a function of “what people want to look at” or what they think is important. In other words, the fact that a message is frequently missed or overlooked does not mean that shoppers think it is unimportant. It simply means that the message was not adequately highlighted on the package...
  3. In the few seconds that shoppers typically spend looking at a package, they can actively consider only three or four primary design elements... Research repeatedly found that adding extra messages does not usually increase packaging viewing time, but instead results in more elements fighting for attention in a ‘zero-sum’ game. Package viewing patterns suggest that the “less is more” axiom is nearly always true...
  4. Package viewing patterns are largely consistent across cultures and product categories because they are driven mainly by human physiology rather than by cultural patterns of preferences.
  5. Is it important for a packaging design to establish a dominant viewing flow that leads consumers from their “start point” to the other critical packaging elements... What doesn’t work well is a balanced lay out in which the main visual starts consumers in the middle and the other design elements surrounding it are all secondary. The ineffective balanced layout forces consumers to ‘randomly’ choose among directions, and this often causes them to miss important / key elements of the labeling.
-

Our warning needs to be the main visual element on the page and highlighted above everything else on the screen. Pages that display the warning must have minimal eye-catching elements to ensure that the user is not distracted from the warning. Eye tracking research [8] shows that "users start by reading across the top line and then look down the page a little and read across again and then continue down the left side."[8] Based upon this we decided to place our warning as the topmost content item on the page. This would be the first and most bold item that varies from the generic website themeing. Beyond this placement, we also decided to add a secondary javascript element of this warning when a user loads the downloads page. We added this extra layer on the downloads page because it is the portal for aquireing the software. We felt an additional layer of warning was warranted. This requires the user to click a button stating that "I Understand" to highlight the importance of the warning. We also provided a second button "I DON'T Understand" which sends the user to a more in-depth explanation of the current "in-security" of the current releases. The commotion site has a vibrant design. It has pastel tones and "speech bubble" section dividers. We assume that a user will quickly start to ignore site content that is themed similarly as navigational content. A warning label must stand out from all common site elements in order to ensure that a user sees it as important content. When we looked at research on font use in warnings we found we had used the most effective warning fonts as our generic site fonts. The Commotion site uses AsapRegular, Ariel, or sans-serif depending upon the availability in a users browser. We were left with size and color to visually differentiate our image. We chose a warning header size that was 1.5 larger than our largest header fonts and using all Caps. Lastly we decided that none of the text on the warning could be text converted to an image format. It is important for translation and text-based browsing that this information is available as html & text. While the warning must stand out from the site,we came across a warning that it must not look like advertising as "Users seldom look at banner ads or anything that remotely looks like an advertisement."[8] In order to accomplish this we decided to use a traditional warning color scheme. This was a simple process, as there are common color combinations to go with different warning levels. "Use a red background with white lettering for danger, orange background with black lettering for warning, and yellow background with black lettering for caution to indicate decreasing levels of hazard."[11] This left us with a orange background. The debate over what icon to use for our warning was quickly extinguished by a study cited in the OSHA's hazard communication guide which stated that "The presence of the signal icon had no significant effect on hazard perception." We decided that adding content that did not effect hazard perception, and had the possibility of distracting a user from the important aspects of the message was not worth the possible risk. Now that we have a warning that will clearly convey the required information, we need to ensure that a user take the desired action. The desired action is for users to NOT use Commotion for communication requiring security unless they are layering other secure communication tools on top or along-side it. We hope to ensure this with the &ldquo;I Don’t Understand&rdquo; document. By placing links next to each warning bullet point to projects that address the security needs that Commotion we hope to lower the “cost of compliance”[12] to a level where the user does not “give up” and will either pair these technologies with Commotion, if there needs require mesh support, or use a security tool that is appropriate for their needs. The final Commotion warning can be seen on our downloads page. This process was an enlightening one. The most important lesson we learned was that a truly good warning is a clear and simple one. Warning labels have been internationally standardized. Our warning would not seem out of place on the side of dangerous machinery in any country. By following standards developed over years of research we can best ensure that our users take the warning with the gravity that it deserves. Creating tools for privacy comes with a deep responsibility to ones users. In an age where already spun news stories can be chopped into misleading 140 character tweets, and when these ideas make there way in to overheard conversations at parties and conferences, the responsibility falls on us to ensure that the public face that we do control is clear about the perils of our technology. A warning is merely one of the steps that we must take to educate our users.

-
  1. Refrences
  2. https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.2.1
  3. http://www.diriwa.org/
  4. https://www.torproject.org/
  5. http://killerapps.foreignpolicy.com/posts/2012/11/05/internet_in_a_suitcase_ready_for_field_testing
  6. https://www.nytimes.com/2011/06/12/world/12internet.html?pagewanted=all&_r=1&
  7. http://www.wired.com/threatlevel/2011/12/internet-suitcase-dc/all/
  8. https://commotionwireless.net/
  9. http://www.usability.gov/articles/newsletter/pubs/032010news.html
  10. https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.3.2
  11. https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.1.8.1
  12. http://www.ismp.org/newsletters/acutecare/articles/20060824.asp
  13. https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.1.6.8
-

Tags:

- - warning  - - label  - - security  - - anonymity  - - privacy  - - research  - - -
- -
+

Tags:

@@ -241,6 +213,35 @@

Tags:

hack day (1)
+
+ +
+ +

2013-02-25 / OTI

+ +

In Part 1, we came up with a list of security features Commotion lacked. We took this list of unimplemented security features and used OSHA's hazard communication guide to clarify our language[9]:

+
  • Instructions are more likely to be followed if consequences are described.
  • Sentences that include a long string of effects or other items can be made clearer by putting them into list.
  • Keep sentences short and direct. Use no more than two subordinate clauses. Use the active voice as much as possible. Use short words of one or two syllables as much as possible. Choose commonly used, familiar words, but avoid colloquialisms and slang.
  • Use only common abbreviations and acronyms, and then give their definition as soon after their first use as possible. Occasionally, however, an abbreviation or acronym may be so familiar to intended audiences that it may be used without a definition. In fact, some may be more familiar than the full name (e.g., OSHA, EPA, SARA, F, C, TLV, and TWA)
+

Our first change was to move the negative “does not” that is stated in the header into each statement. This ensures that each statement can be read out of context of the whole with full meaning intact and gave us greater freedom in our wording on each line. We then switched the focus from attacks that Commotion does not protect against to consequences that come from lack of feature sets. For example, we removed "malware" in favor of highlighting the result of data and identity insecurity. We then went through each statement to remove jargon/acronyms and make the language more active. WARNING!Commotion:

+
  • Cannot hide your identity
  • Does not prevent monitoring of internet traffic
  • Does not provide strong security against monitoring over the mesh
  • Can be jammed with radio/data-interference
+

In accordance to ANZI "Product Safety Signs and Labels" [10], the term "warning indicates a potentially hazardous situation which, if not avoided, could result in death or serious injury." We felt that this was appropriate for the current non-secure release of Commotion. The next highest level, "danger" is "to be limited to the most extreme situations." We will reserve this warning for our future release of a "secure" Commotion distribution to emphasize the ways in which it does not provide full security. We hope this escalation will signal to users of Commotion for secure communication that they put themselves in danger by assuming security where it does not exist. In the future, as we have translation done on our documentation, we will also work with translators to ensure that region-specific translations are not direct translations, but instead clearly convey the warnings to the users in the most understandable way. With our language solidified, we started on our second question: How do we ensure the "ability of the individual reading [the warning] to understand the information sufficiently to take the desired action"[1] for their specific situation? The first thing that we did was look for existing literature on warning labels in software, which was sorely lacking. So, we turned to warning labels on tobacco, drugs, and dangerous machinery. "A review of the science base to support the development of health warnings for tobacco packages" is an interesting read for its own merit, and was a great resource in helping us ensure that the warning was in the best possible site placement to reach our users.

+
  1. ...shoppers typically start at the dominant visual element (often the brand name), and are then drawn to the next strongest element (usually the next most dominant visual element).
  2. A related and important point is that viewing patterns are driven by packaging layout rather than a function of “what people want to look at” or what they think is important. In other words, the fact that a message is frequently missed or overlooked does not mean that shoppers think it is unimportant. It simply means that the message was not adequately highlighted on the package...
  3. In the few seconds that shoppers typically spend looking at a package, they can actively consider only three or four primary design elements... Research repeatedly found that adding extra messages does not usually increase packaging viewing time, but instead results in more elements fighting for attention in a ‘zero-sum’ game. Package viewing patterns suggest that the “less is more” axiom is nearly always true...
  4. Package viewing patterns are largely consistent across cultures and product categories because they are driven mainly by human physiology rather than by cultural patterns of preferences.
  5. Is it important for a packaging design to establish a dominant viewing flow that leads consumers from their “start point” to the other critical packaging elements... What doesn’t work well is a balanced lay out in which the main visual starts consumers in the middle and the other design elements surrounding it are all secondary. The ineffective balanced layout forces consumers to ‘randomly’ choose among directions, and this often causes them to miss important / key elements of the labeling.
+

Our warning needs to be the main visual element on the page and highlighted above everything else on the screen. Pages that display the warning must have minimal eye-catching elements to ensure that the user is not distracted from the warning. Eye tracking research [8] shows that "users start by reading across the top line and then look down the page a little and read across again and then continue down the left side."[8] Based upon this we decided to place our warning as the topmost content item on the page. This would be the first and most bold item that varies from the generic website themeing. Beyond this placement, we also decided to add a secondary javascript element of this warning when a user loads the downloads page. We added this extra layer on the downloads page because it is the portal for aquireing the software. We felt an additional layer of warning was warranted. This requires the user to click a button stating that "I Understand" to highlight the importance of the warning. We also provided a second button "I DON'T Understand" which sends the user to a more in-depth explanation of the current "in-security" of the current releases. The commotion site has a vibrant design. It has pastel tones and "speech bubble" section dividers. We assume that a user will quickly start to ignore site content that is themed similarly as navigational content. A warning label must stand out from all common site elements in order to ensure that a user sees it as important content. When we looked at research on font use in warnings we found we had used the most effective warning fonts as our generic site fonts. The Commotion site uses AsapRegular, Ariel, or sans-serif depending upon the availability in a users browser. We were left with size and color to visually differentiate our image. We chose a warning header size that was 1.5 larger than our largest header fonts and using all Caps. Lastly we decided that none of the text on the warning could be text converted to an image format. It is important for translation and text-based browsing that this information is available as html & text. While the warning must stand out from the site,we came across a warning that it must not look like advertising as "Users seldom look at banner ads or anything that remotely looks like an advertisement."[8] In order to accomplish this we decided to use a traditional warning color scheme. This was a simple process, as there are common color combinations to go with different warning levels. "Use a red background with white lettering for danger, orange background with black lettering for warning, and yellow background with black lettering for caution to indicate decreasing levels of hazard."[11] This left us with a orange background. The debate over what icon to use for our warning was quickly extinguished by a study cited in the OSHA's hazard communication guide which stated that "The presence of the signal icon had no significant effect on hazard perception." We decided that adding content that did not effect hazard perception, and had the possibility of distracting a user from the important aspects of the message was not worth the possible risk. Now that we have a warning that will clearly convey the required information, we need to ensure that a user take the desired action. The desired action is for users to NOT use Commotion for communication requiring security unless they are layering other secure communication tools on top or along-side it. We hope to ensure this with the &ldquo;I Don’t Understand&rdquo; document. By placing links next to each warning bullet point to projects that address the security needs that Commotion we hope to lower the “cost of compliance”[12] to a level where the user does not “give up” and will either pair these technologies with Commotion, if there needs require mesh support, or use a security tool that is appropriate for their needs. The final Commotion warning can be seen on our downloads page. This process was an enlightening one. The most important lesson we learned was that a truly good warning is a clear and simple one. Warning labels have been internationally standardized. Our warning would not seem out of place on the side of dangerous machinery in any country. By following standards developed over years of research we can best ensure that our users take the warning with the gravity that it deserves. Creating tools for privacy comes with a deep responsibility to ones users. In an age where already spun news stories can be chopped into misleading 140 character tweets, and when these ideas make there way in to overheard conversations at parties and conferences, the responsibility falls on us to ensure that the public face that we do control is clear about the perils of our technology. A warning is merely one of the steps that we must take to educate our users.

+
  1. Refrences
  2. https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.2.1
  3. http://www.diriwa.org/
  4. https://www.torproject.org/
  5. http://killerapps.foreignpolicy.com/posts/2012/11/05/internet_in_a_suitcase_ready_for_field_testing
  6. https://www.nytimes.com/2011/06/12/world/12internet.html?pagewanted=all&_r=1&
  7. http://www.wired.com/threatlevel/2011/12/internet-suitcase-dc/all/
  8. https://commotionwireless.net/
  9. http://www.usability.gov/articles/newsletter/pubs/032010news.html
  10. https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.3.2
  11. https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.1.8.1
  12. http://www.ismp.org/newsletters/acutecare/articles/20060824.asp
  13. https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.1.6.8
+

Tags:

+ + warning  + + label  + + security  + + anonymity  + + privacy  + + research  + +
@@ -263,6 +264,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2013/03/13/new-commotion-release-dr1-ready-testing/index.html b/test.commotion/_site/blog/2013/03/13/new-commotion-release-dr1-ready-testing/index.html index 8e0f1277..fa5490bb 100644 --- a/test.commotion/_site/blog/2013/03/13/new-commotion-release-dr1-ready-testing/index.html +++ b/test.commotion/_site/blog/2013/03/13/new-commotion-release-dr1-ready-testing/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,19 +107,7 @@

New Commotion Release (DR1) Ready for Testing

-
- -

2013-03-13 / OTI

- -

Commotion’s first developer release (DR1) is now available for testing. This version replaces our September 2012 pre-release (PR3) and adds several new features. Though Commotion developers tested each component feature, we will begin extensive pre-release testing of the entire DR1 suite in the coming weeks. We hope you will join us in testing the new components. Pre-built Commotion packages for Ubiquiti routers and Android devices can be found at https://commotionwireless.net/download, with DR1 listed under Nightly Builds and PR3 listed as Stable. The download page also provides links to the Commotion source code for those who wish to build their own packages. We have pre-built images for testing on Ubiquiti wireless hardware. The source code includes instructions for building Commotion’s test release on other hardware for those that wish to test on their own devices. The DR1 release brings a complete overhaul to the Commotion system while still ensuring compatibility with PR3 release Commotion nodes. Forward-facing features include a new theme, easy “quickstart” node configuration, application announcement and discovery, and a one-click troubleshooting tool. Behind the scenes, DR1 contains a core Commotion daemon and new cryptographic system. The quickstart tool provides an easy interface for node configuration. The Commotion daemon provides a common mesh network management interface through an embedded library, and forms the core of future Commotion platform development. Commotion’s new application suite uses mDNS to announce local applications across the network. Users can find local applications using the router’s web-based application portal. Node owners can easily manage and customize application portals for better community application support. The application portal integrates the Serval Project’s key management daemon, which provides transparent message encryption and authentication. Finally, the debugging helper creates custom, downloadable documents for offline debugging by network administrators. Each of these tools still requires thorough testing to ensure they are both stable and well documented. If you are an interested user, developer, hacker, or are just plain interested, we would love to hear your feedback. Following initial internal testing, DR1 will undergo lab testing on an eight-node physical test environment. Then we will install on the Open Technology Institute’s (OTI’s) 18-node testbed community network. Once the software is deemed stable, we will deploy it on an active six-node community wireless network for user testing. We will update the documentation to incorporate user feedback once testing is completed. After the build has been thoroughly tested and DR1 has become stable, we will update the warning label on the downloads page to reflect the capabilities and limitations of this release. We will then bring the other Commotion platforms up to feature parity with the DR1 Commotion OpenWRT release.

-

Tags:

- - nil}">{"categories"=>nil}  - - -
- -
+

Tags:

@@ -224,6 +213,18 @@

Tags:

hack day (1)
+
+ +
+ +

2013-03-13 / OTI

+ +

Commotion’s first developer release (DR1) is now available for testing. This version replaces our September 2012 pre-release (PR3) and adds several new features. Though Commotion developers tested each component feature, we will begin extensive pre-release testing of the entire DR1 suite in the coming weeks. We hope you will join us in testing the new components. Pre-built Commotion packages for Ubiquiti routers and Android devices can be found at https://commotionwireless.net/download, with DR1 listed under Nightly Builds and PR3 listed as Stable. The download page also provides links to the Commotion source code for those who wish to build their own packages. We have pre-built images for testing on Ubiquiti wireless hardware. The source code includes instructions for building Commotion’s test release on other hardware for those that wish to test on their own devices. The DR1 release brings a complete overhaul to the Commotion system while still ensuring compatibility with PR3 release Commotion nodes. Forward-facing features include a new theme, easy “quickstart” node configuration, application announcement and discovery, and a one-click troubleshooting tool. Behind the scenes, DR1 contains a core Commotion daemon and new cryptographic system. The quickstart tool provides an easy interface for node configuration. The Commotion daemon provides a common mesh network management interface through an embedded library, and forms the core of future Commotion platform development. Commotion’s new application suite uses mDNS to announce local applications across the network. Users can find local applications using the router’s web-based application portal. Node owners can easily manage and customize application portals for better community application support. The application portal integrates the Serval Project’s key management daemon, which provides transparent message encryption and authentication. Finally, the debugging helper creates custom, downloadable documents for offline debugging by network administrators. Each of these tools still requires thorough testing to ensure they are both stable and well documented. If you are an interested user, developer, hacker, or are just plain interested, we would love to hear your feedback. Following initial internal testing, DR1 will undergo lab testing on an eight-node physical test environment. Then we will install on the Open Technology Institute’s (OTI’s) 18-node testbed community network. Once the software is deemed stable, we will deploy it on an active six-node community wireless network for user testing. We will update the documentation to incorporate user feedback once testing is completed. After the build has been thoroughly tested and DR1 has become stable, we will update the warning label on the downloads page to reflect the capabilities and limitations of this release. We will then bring the other Commotion platforms up to feature parity with the DR1 Commotion OpenWRT release.

+

Tags:

+ + nil}">{"categories"=>nil}  + +
@@ -246,6 +247,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2013/03/28/open-technology-institute-endorses-battle-mesh-v6/index.html b/test.commotion/_site/blog/2013/03/28/open-technology-institute-endorses-battle-mesh-v6/index.html index d0ebe2fa..842a4360 100644 --- a/test.commotion/_site/blog/2013/03/28/open-technology-institute-endorses-battle-mesh-v6/index.html +++ b/test.commotion/_site/blog/2013/03/28/open-technology-institute-endorses-battle-mesh-v6/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,25 +107,7 @@

The Open Technology Institute endorses the Battle of th
-
- -

2013-03-28 / s2e

- -

Since 2009, wireless mesh enthusiasts and community networking activists from across the globe have come together for a tournament of a social nature: "Wireless Battle of the Mesh". Each battle is held in a different European location, creating a unique series of testbeds for this band of hacktivists and wireless innovators to examine the performance of the various mesh data routing protocols. Wireless mesh projects are judged on many features including network capacity, recovery, and node-discovery. The creators and implementers of protocols such as Babel, B.A.T.M.A.N., BMX, OLSR, and 802.11s come together each year to compete and swap notes and code. This year’s events will be held at the University of Aalborg, Denmark, from Monday, April 15th through Sunday, April 21st. The Open Technology Institute (OTI) sees Battlemesh as a great knowledge sharing event that has, and continues to be, critically important to groundbreaking innovation in the field of wireless mesh networking. Events like these help foster the development of grassroots community networks around the globe. OTI endorses and supports the Battle of the Mesh v6 for its crucial role in advancing the state of the art. OTI will be sending a team of technologists to the Battle of the Mesh to participate in the event’s talks and to help with network setup. OTI will also donate hardware to help extend the pool of available network devices. To see the list of the endorsers or learn more about the project, please visit the main Battlemesh website.

-

Tags:

- - battlemesh  - - mesh  - - olsr  - - testing  - - -
- -
+

Tags:

@@ -230,6 +213,24 @@

Tags:

hack day (1)
+
+ +
+ +

2013-03-28 / s2e

+ +

Since 2009, wireless mesh enthusiasts and community networking activists from across the globe have come together for a tournament of a social nature: "Wireless Battle of the Mesh". Each battle is held in a different European location, creating a unique series of testbeds for this band of hacktivists and wireless innovators to examine the performance of the various mesh data routing protocols. Wireless mesh projects are judged on many features including network capacity, recovery, and node-discovery. The creators and implementers of protocols such as Babel, B.A.T.M.A.N., BMX, OLSR, and 802.11s come together each year to compete and swap notes and code. This year’s events will be held at the University of Aalborg, Denmark, from Monday, April 15th through Sunday, April 21st. The Open Technology Institute (OTI) sees Battlemesh as a great knowledge sharing event that has, and continues to be, critically important to groundbreaking innovation in the field of wireless mesh networking. Events like these help foster the development of grassroots community networks around the globe. OTI endorses and supports the Battle of the Mesh v6 for its crucial role in advancing the state of the art. OTI will be sending a team of technologists to the Battle of the Mesh to participate in the event’s talks and to help with network setup. OTI will also donate hardware to help extend the pool of available network devices. To see the list of the endorsers or learn more about the project, please visit the main Battlemesh website.

+

Tags:

+ + battlemesh  + + mesh  + + olsr  + + testing  + +
@@ -252,6 +253,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2013/06/05/building-community-controlled-digital-infrastructure-detroit/index.html b/test.commotion/_site/blog/2013/06/05/building-community-controlled-digital-infrastructure-detroit/index.html index c7fbbd3f..1856ba7c 100644 --- a/test.commotion/_site/blog/2013/06/05/building-community-controlled-digital-infrastructure-detroit/index.html +++ b/test.commotion/_site/blog/2013/06/05/building-community-controlled-digital-infrastructure-detroit/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,29 +107,7 @@

Building Community Controlled Digital Infrastructure in
-
- -

2013-06-05 / georgia

- - -

Tags:

- - detroit  - - community wireless  - - digital stewards  - - mesh  - - amp  - - amc  - - -
- -
+

Tags:

@@ -234,6 +213,28 @@

Tags:

hack day (1)
+
+ +
+ +

2013-06-05 / georgia

+ + +

Tags:

+ + detroit  + + community wireless  + + digital stewards  + + mesh  + + amp  + + amc  + +
@@ -256,6 +257,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2013/06/05/commotion-dr1-stable-release-notes-dr11/index.html b/test.commotion/_site/blog/2013/06/05/commotion-dr1-stable-release-notes-dr11/index.html index 0d937ba0..a8bb9b04 100644 --- a/test.commotion/_site/blog/2013/06/05/commotion-dr1-stable-release-notes-dr11/index.html +++ b/test.commotion/_site/blog/2013/06/05/commotion-dr1-stable-release-notes-dr11/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,51 +107,7 @@

Commotion DR1 Stable Release Notes (DR1.1)

-
- -

2013-06-05 / andrew

- -

Developer Release 1.1 is the first stable release of the DR1 series. This release is the beginning of our new stable branch, and represents a significant step forward from our previous stable release.

-

What is a Commotion release?

-

Commotion release versions represent a target set of features for the entire project. Software packages for individual platforms (Linux, Windows, etc.) may be in different stages of development, and are labeled according to their supported features.

-

Platform Availability

-

Currently, only the OpenWRT-based router firmware is DR1 compatible. Other platforms are under active development and are being brought up to feature parity. Current platform revisions can be found on the Official Version Feature Targets page. Pre-compiled software images are available on the Commotion Download page.

-

Features:

-

-
    -
  • **Easy-to-use setup wizard:** The Commotion Quickstart wizard provides a simple, one-step interface for setting up a Commotion node.
    • -
  • **Local applications:** The Commotion Apps Portal is an interface for creating and browsing for local network applications.
    • -
  • **Common platform for managing settings:** The Commotion Daemon provides a common management interface for maintaining the configurations of different community networks.
    • -
  • **Encryption tools:** Commotion configures industry-standard IBSS-RSN encryption by default, and provides the Serval crypto API to aid developers in creating secure applications.
    • -
  • **Consistent visual style:** New Commotion releases are all styled in accordance with the Commotion Human Interface Guidelines (http://commotionwireless.net/docs/hig/introduction).
    • -
  • **Simplified debugging:** A new Commotion Debugging Helper tool makes it easy to retrieve useful troubleshooting information from a node in the event of a network problem.
    • -
-

-

Fixes

-

Innumerable fixes and changes went into this release since Preview Release 3 (PR3), the previous stable branch. A complete list can be found on the Commotion project site’s issue tracker.

-

Included Components

-

- -

Tags:

- - release  - - -
- -
+

Tags:

@@ -256,6 +213,50 @@

Tags:

hack day (1)
+
+ +
+ +

2013-06-05 / andrew

+ +

Developer Release 1.1 is the first stable release of the DR1 series. This release is the beginning of our new stable branch, and represents a significant step forward from our previous stable release.

+

What is a Commotion release?

+

Commotion release versions represent a target set of features for the entire project. Software packages for individual platforms (Linux, Windows, etc.) may be in different stages of development, and are labeled according to their supported features.

+

Platform Availability

+

Currently, only the OpenWRT-based router firmware is DR1 compatible. Other platforms are under active development and are being brought up to feature parity. Current platform revisions can be found on the Official Version Feature Targets page. Pre-compiled software images are available on the Commotion Download page.

+

Features:

+

+
    +
  • **Easy-to-use setup wizard:** The Commotion Quickstart wizard provides a simple, one-step interface for setting up a Commotion node.
    • +
  • **Local applications:** The Commotion Apps Portal is an interface for creating and browsing for local network applications.
    • +
  • **Common platform for managing settings:** The Commotion Daemon provides a common management interface for maintaining the configurations of different community networks.
    • +
  • **Encryption tools:** Commotion configures industry-standard IBSS-RSN encryption by default, and provides the Serval crypto API to aid developers in creating secure applications.
    • +
  • **Consistent visual style:** New Commotion releases are all styled in accordance with the Commotion Human Interface Guidelines (http://commotionwireless.net/docs/hig/introduction).
    • +
  • **Simplified debugging:** A new Commotion Debugging Helper tool makes it easy to retrieve useful troubleshooting information from a node in the event of a network problem.
    • +
+

+

Fixes

+

Innumerable fixes and changes went into this release since Preview Release 3 (PR3), the previous stable branch. A complete list can be found on the Commotion project site’s issue tracker.

+

Included Components

+

+ +

Tags:

+ + release  + +
@@ -278,6 +279,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2013/06/05/serval-mesh-extender-field-trial-national-mall/index.html b/test.commotion/_site/blog/2013/06/05/serval-mesh-extender-field-trial-national-mall/index.html index 60e797ba..f6ae8bdc 100644 --- a/test.commotion/_site/blog/2013/06/05/serval-mesh-extender-field-trial-national-mall/index.html +++ b/test.commotion/_site/blog/2013/06/05/serval-mesh-extender-field-trial-national-mall/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,27 +107,7 @@

Serval Mesh Extender Field Trial on the National Mall
-
- -

2013-06-05 / OTI

- -

On an uncharacteristically chilly May morning, members of the Commotion and Serval projects set out for the National Mall in Washington, DC to test Serval's latest piece of hardware: the Mesh Extender. Commotion Wireless is an open-source toolkit of software, documentation, and training materials that strengthens communities by allowing them to build their own local communication infrastructure. Serval is a mesh networking software designed to act as an ad hoc communications network where other infrastructure is either absent or unavailable – such as in remote areas or disaster scenarios. Some of us stood at the Washington Monument while others were at the Lincoln Memorial – a distance of nearly a mile. Using two Mesh Extenders, we successfully sent text messages and shared files between our phones (running Serval) – entirely independent of the cellular infrastructure. On the way back to the office, we hopped on the Metro – DC's subway system – to run another impromptu field test. From opposite ends of the train, we were able to send and receive messages through six subway cars (and their passengers) while the train was moving. That meant we could do something Metro riders usually can't – send and receive messages while in the subway tunnels. These results represent a significant breakthrough, as until now Serval and Commotion have been limited by the relatively short range and low power of Wi-Fi. In addition to increasing range and power, the Mesh Extender removes a major obstacle to widespread adoption of mesh for mobile phones – rooting. Normally a prerequisite for Androids to connect to a mesh network, this technically challenging process for installing a new operating system can cause problems down the road for the rooted phone. In this case, the Mesh Extender routes the messages, not the users' phones, eliminating the need for rooting. However, the Mesh Extender is still a prototype. Software issues make voice calls possible but indecipherable. Further development, including better error correction and noise cancellation, will allow for not only voice calls but potentially even longer-distance connections. Despite these remaining challenges, the Mesh Extender is a huge step towards reliable decentralized infrastructure. A device with multiple radios and a small processor, the Mesh Extender essentially acts as a relay between phones running Serval software. It is lightweight, portable, and relatively cheap and easy to build. The parts can be purchased and assembled for as little as $99. Impressively, the battery can support three to five days of continuous use. The Mesh Extender uses omni-directional antennas (as opposed to point-to-point links), which make for much easier set up and configuration, and allow for truly mobile networks. The Mesh Extender operates simultaneously on the 2.4 GHz and 900 MHz bands, both of which are unlicensed. This allows phones running Serval to tether to the closest Mesh Extender over Wi-Fi (2.4 GHz), while the Mesh Extenders themselves communicate over the 900 MHz band, which is both less congested and has better propagation characteristics.

-

Tags:

- - messaging  - - applications  - - chat  - - site visits  - - serval  - - -
- -
+

Tags:

@@ -232,6 +213,26 @@

Tags:

hack day (1)
+
+ +
+ +

2013-06-05 / OTI

+ +

On an uncharacteristically chilly May morning, members of the Commotion and Serval projects set out for the National Mall in Washington, DC to test Serval's latest piece of hardware: the Mesh Extender. Commotion Wireless is an open-source toolkit of software, documentation, and training materials that strengthens communities by allowing them to build their own local communication infrastructure. Serval is a mesh networking software designed to act as an ad hoc communications network where other infrastructure is either absent or unavailable – such as in remote areas or disaster scenarios. Some of us stood at the Washington Monument while others were at the Lincoln Memorial – a distance of nearly a mile. Using two Mesh Extenders, we successfully sent text messages and shared files between our phones (running Serval) – entirely independent of the cellular infrastructure. On the way back to the office, we hopped on the Metro – DC's subway system – to run another impromptu field test. From opposite ends of the train, we were able to send and receive messages through six subway cars (and their passengers) while the train was moving. That meant we could do something Metro riders usually can't – send and receive messages while in the subway tunnels. These results represent a significant breakthrough, as until now Serval and Commotion have been limited by the relatively short range and low power of Wi-Fi. In addition to increasing range and power, the Mesh Extender removes a major obstacle to widespread adoption of mesh for mobile phones – rooting. Normally a prerequisite for Androids to connect to a mesh network, this technically challenging process for installing a new operating system can cause problems down the road for the rooted phone. In this case, the Mesh Extender routes the messages, not the users' phones, eliminating the need for rooting. However, the Mesh Extender is still a prototype. Software issues make voice calls possible but indecipherable. Further development, including better error correction and noise cancellation, will allow for not only voice calls but potentially even longer-distance connections. Despite these remaining challenges, the Mesh Extender is a huge step towards reliable decentralized infrastructure. A device with multiple radios and a small processor, the Mesh Extender essentially acts as a relay between phones running Serval software. It is lightweight, portable, and relatively cheap and easy to build. The parts can be purchased and assembled for as little as $99. Impressively, the battery can support three to five days of continuous use. The Mesh Extender uses omni-directional antennas (as opposed to point-to-point links), which make for much easier set up and configuration, and allow for truly mobile networks. The Mesh Extender operates simultaneously on the 2.4 GHz and 900 MHz bands, both of which are unlicensed. This allows phones running Serval to tether to the closest Mesh Extender over Wi-Fi (2.4 GHz), while the Mesh Extenders themselves communicate over the 900 MHz band, which is both less congested and has better propagation characteristics.

+

Tags:

+ + messaging  + + applications  + + chat  + + site visits  + + serval  + +
@@ -254,6 +255,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2013/07/01/commotion-travels-india-first-international-workshop/index.html b/test.commotion/_site/blog/2013/07/01/commotion-travels-india-first-international-workshop/index.html index 43a0844b..f726a85f 100644 --- a/test.commotion/_site/blog/2013/07/01/commotion-travels-india-first-international-workshop/index.html +++ b/test.commotion/_site/blog/2013/07/01/commotion-travels-india-first-international-workshop/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,53 +107,7 @@

Commotion Travels to India for first International Work
-
- -

2013-07-01 / gerety

- -

- -

The Open Technology Institute traveled to Dharamshala, India the first week of June for the first international Commotion Wireless workshop. Working with our local hosting partner AirJaldi, we convened over a dozen community technologists from across India and Nepal in the town nestled in the foothills of the Himalayas to get their feedback on OTI’s Commotion mesh technology. The workshop was an opportunity to strengthen not only the recent Developer Release 1.1 of the software, but also a global network of technology designers, implementers, and users who see users and communities as the prime source of innovation in information and communications technology. Some important ideas from the field, conversation, and debate that we brought home with us included:

-
    -
  • Good community technology is defined by the ability of that community to break and repair it themselves.
    • -
  • Successful technology training and adoption needs a clear and common use in the participant's life. If they don't use it regularly, they won't retain the information, or use the technology.
    • -
  • Internet access is not always the most important consideration - a local network can and should provide a local application first and foremost.
    • -
  • Strong, lasting networks are built through participatory planning and community engagement.
    • -
-

Over the course of the five day workshop, participants built a pilot Commotion network, developed plans for future networks and rallied around a common belief that communities should be able to build and govern their own communications infrastructure. The workshop took place the first week of June at the beautiful Dolma Ling Nunnery, and was co-hosted by AirJaldi, which has partnered on experimental technologies and workshops for many years. The diverse group of participants included network engineers, broadcast engineers, community organizers, educators and policy advocates from AirJaldi, Digital Empowerment Foundation, Gnowledge, IRMA, Janastu, Mahiti, Mojolab, Nepal Wireless, Nomad, and Open Knowledge Foundation. Attendees at the workshop brought visions for community technology, a desire to use mesh wireless in their work, and network plans to solidify. On the first day, we established a common view that building a network is a complex social process, not only (or even primarily) a technical challenge, and that community governance and training are critical components of this process. In addition, by the end of that first day, participants had installed the Commotion software on Ubiquiti wireless routers, learned to configure and mesh those nodes, and then set off on their own to create a mesh network in and around their hotels, linking to the Commotion-powered node installed on the workshop rooftop across town.
Using a shared visual language to plan and design a network. The second day focused on planning mesh networks. Participants used a common visual language developed in our training programs in Detroit to draw plans for the networks they would like to build with Commotion. Later in the day, we went outside to experiment with Servalmessaging (on Android devices), MediaGrid, and Commotion Linux on a mesh network created with battery-powered nodes. We learned a few good lessons about doing too many experimental things at once! On the third and fourth days, the participants split into two teams and went into the field to build a nine node pilot network, combining three medium-distance links with a denser omni-directional mesh in the town of Norbulingka. The AirJaldi network provided two network gateways for Internet access. During the construction and testing process, we found that, even for a small network, there were many interesting complexities. After spending hours in the sun, OTI staff and the participants returned to the workshop space to experiment with Osmocom, an open implementation of the GSM standard for mobile telephony, and other technologies.
We spent so long trying to get the right angle for the long-distance link, we did not even realize it was working, and we had completed the mesh network. The last day involved more experimentation as well as discussions about the regulatory environment in India, and the possibilities for using mesh technology in crisis response. By the end of the workshop, some participants successfully installed Commotion Linux on their laptops, a participant meshed his Raspberry Pi device, and several maps and plans for new networks hung on the wall. We returned with invaluable suggestions for improvements to Commotion, including a list of accessible and affordable routers that we should actively test and support. The workshop discussions were full of memorable visions for the Internet, community technology, and mesh wireless networks, where different groups of participants envisioned:

-
    -
  • “The internet as a free, secure, decentralized, and inclusive media for all communities to overcome economic marginalization and local problems.”
    • -
  • Community-owned networks “that are built with low-cost devices, equally accessed, and resistant to blackouts.”
    • -
  • Community technology that is “by communities, for communities and integrating across various devices and technologies,” “peer-to-peer without centralized control or surveillance,” and “enabling local content creation and consumption and in the local context and language.”
    • -
-


You never know when you might need a router and a battery pack! Another common thread throughout the workshop was a shared approach to community tech education. Small groups brainstormed the following guidelines:

-
    -
  • engage in peer-to-peer learning because it helps demystify technology
    • -
  • create a level of comfort around technology
    • -
  • build an awareness in communities about the available technology, so they can build from the knowledge and resources available
    • -
  • above all, break the fear of technology and show users that technology can be taken apart and put back together.
    • -
-

To this last point, one participant threw his phone to the ground, picked it up and put it back together - all to highlight the need for people to be able to break and fix the technology they rely on. This theme continued throughout the workshop when the network needed troubleshooting or equipment did not work as expected. The process of troubleshooting and experimentation was an important component of the learning, and led to the discovery of a few bugs in the newest DR1.1 release. Even more valuable was the feedback from participants, which will continue to inform the direction of the Commotion project. The ideas and lessons coming out of the workshop are already being applied in the office to the Commotion code, to the training tools we use in our work, and in the networks we partner with in Detroit and Brooklyn. At the end of the week-long workshop the network was working well, and demonstrated the properties of a dynamic mesh by allowing us to connect a portable node as we moved through a grassy field, down the dirt path to a rooftop restaurant to toast our successes and future collaborations.

-

Tags:

- - mesh  - - site visits  - - gource  - - git  - - visualization  - - troubleshooting  - - recommendations  - - -
- -
+

Tags:

@@ -258,6 +213,52 @@

Tags:

hack day (1)
+
+ +
+ +

2013-07-01 / gerety

+ +

+ +

The Open Technology Institute traveled to Dharamshala, India the first week of June for the first international Commotion Wireless workshop. Working with our local hosting partner AirJaldi, we convened over a dozen community technologists from across India and Nepal in the town nestled in the foothills of the Himalayas to get their feedback on OTI’s Commotion mesh technology. The workshop was an opportunity to strengthen not only the recent Developer Release 1.1 of the software, but also a global network of technology designers, implementers, and users who see users and communities as the prime source of innovation in information and communications technology. Some important ideas from the field, conversation, and debate that we brought home with us included:

+
    +
  • Good community technology is defined by the ability of that community to break and repair it themselves.
    • +
  • Successful technology training and adoption needs a clear and common use in the participant's life. If they don't use it regularly, they won't retain the information, or use the technology.
    • +
  • Internet access is not always the most important consideration - a local network can and should provide a local application first and foremost.
    • +
  • Strong, lasting networks are built through participatory planning and community engagement.
    • +
+

Over the course of the five day workshop, participants built a pilot Commotion network, developed plans for future networks and rallied around a common belief that communities should be able to build and govern their own communications infrastructure. The workshop took place the first week of June at the beautiful Dolma Ling Nunnery, and was co-hosted by AirJaldi, which has partnered on experimental technologies and workshops for many years. The diverse group of participants included network engineers, broadcast engineers, community organizers, educators and policy advocates from AirJaldi, Digital Empowerment Foundation, Gnowledge, IRMA, Janastu, Mahiti, Mojolab, Nepal Wireless, Nomad, and Open Knowledge Foundation. Attendees at the workshop brought visions for community technology, a desire to use mesh wireless in their work, and network plans to solidify. On the first day, we established a common view that building a network is a complex social process, not only (or even primarily) a technical challenge, and that community governance and training are critical components of this process. In addition, by the end of that first day, participants had installed the Commotion software on Ubiquiti wireless routers, learned to configure and mesh those nodes, and then set off on their own to create a mesh network in and around their hotels, linking to the Commotion-powered node installed on the workshop rooftop across town.
Using a shared visual language to plan and design a network. The second day focused on planning mesh networks. Participants used a common visual language developed in our training programs in Detroit to draw plans for the networks they would like to build with Commotion. Later in the day, we went outside to experiment with Servalmessaging (on Android devices), MediaGrid, and Commotion Linux on a mesh network created with battery-powered nodes. We learned a few good lessons about doing too many experimental things at once! On the third and fourth days, the participants split into two teams and went into the field to build a nine node pilot network, combining three medium-distance links with a denser omni-directional mesh in the town of Norbulingka. The AirJaldi network provided two network gateways for Internet access. During the construction and testing process, we found that, even for a small network, there were many interesting complexities. After spending hours in the sun, OTI staff and the participants returned to the workshop space to experiment with Osmocom, an open implementation of the GSM standard for mobile telephony, and other technologies.
We spent so long trying to get the right angle for the long-distance link, we did not even realize it was working, and we had completed the mesh network. The last day involved more experimentation as well as discussions about the regulatory environment in India, and the possibilities for using mesh technology in crisis response. By the end of the workshop, some participants successfully installed Commotion Linux on their laptops, a participant meshed his Raspberry Pi device, and several maps and plans for new networks hung on the wall. We returned with invaluable suggestions for improvements to Commotion, including a list of accessible and affordable routers that we should actively test and support. The workshop discussions were full of memorable visions for the Internet, community technology, and mesh wireless networks, where different groups of participants envisioned:

+
    +
  • “The internet as a free, secure, decentralized, and inclusive media for all communities to overcome economic marginalization and local problems.”
    • +
  • Community-owned networks “that are built with low-cost devices, equally accessed, and resistant to blackouts.”
    • +
  • Community technology that is “by communities, for communities and integrating across various devices and technologies,” “peer-to-peer without centralized control or surveillance,” and “enabling local content creation and consumption and in the local context and language.”
    • +
+


You never know when you might need a router and a battery pack! Another common thread throughout the workshop was a shared approach to community tech education. Small groups brainstormed the following guidelines:

+
    +
  • engage in peer-to-peer learning because it helps demystify technology
    • +
  • create a level of comfort around technology
    • +
  • build an awareness in communities about the available technology, so they can build from the knowledge and resources available
    • +
  • above all, break the fear of technology and show users that technology can be taken apart and put back together.
    • +
+

To this last point, one participant threw his phone to the ground, picked it up and put it back together - all to highlight the need for people to be able to break and fix the technology they rely on. This theme continued throughout the workshop when the network needed troubleshooting or equipment did not work as expected. The process of troubleshooting and experimentation was an important component of the learning, and led to the discovery of a few bugs in the newest DR1.1 release. Even more valuable was the feedback from participants, which will continue to inform the direction of the Commotion project. The ideas and lessons coming out of the workshop are already being applied in the office to the Commotion code, to the training tools we use in our work, and in the networks we partner with in Detroit and Brooklyn. At the end of the week-long workshop the network was working well, and demonstrated the properties of a dynamic mesh by allowing us to connect a portable node as we moved through a grassy field, down the dirt path to a rooftop restaurant to toast our successes and future collaborations.

+

Tags:

+ + mesh  + + site visits  + + gource  + + git  + + visualization  + + troubleshooting  + + recommendations  + +
@@ -280,6 +281,21 @@

Tags:

+ + + diff --git a/test.commotion/_site/blog/2013/07/11/commotion-development-progress-visualized/index.html b/test.commotion/_site/blog/2013/07/11/commotion-development-progress-visualized/index.html index eaf25a0a..c3065187 100644 --- a/test.commotion/_site/blog/2013/07/11/commotion-development-progress-visualized/index.html +++ b/test.commotion/_site/blog/2013/07/11/commotion-development-progress-visualized/index.html @@ -16,7 +16,7 @@ -
+
@@ -30,6 +30,7 @@
+ @@ -106,23 +107,7 @@

Commotion Development Progress Visualized

-
- -

2013-07-11 / s2e

- -

One challenge of working on a software project is showing a non-developer the vibrancy of the code base. Since Commotion is being developed on multiple platforms and through a variety of interacting packages on each platform, we can’t even point at a specific code repository or downloadable to show what work has taken place. We recently became aware of Gource, a open-source project that aims to make this possible. As described on Gource’s website, “Software projects are displayed by Gource as an animated tree with the root directory of the project at its center. Directories appear as branches with files as leaves. Developers can be seen working on the tree at the times they contributed to the project.”

-