On Wed, Jul 10, 2013 at 5:28 PM, Mitar <mitar@tnode.com> wrote:

Hi!

I would just raise concerns about captive portal/splash screen. We had
that for some time and it was much more an issue than worth. It was our
primary reason why people said that the network does not work.

People wondered why things don't work. For example Skype and e-mail. And
the concept that they have first to open some webpage. And then Skype
will start working. This was made easier now since OSes detect captive
portal and display information about that. But still. Smart phones still
have this issue.

They do? My phone is pretty old and it doesn't have this issue. Most free wifi these days have a captive portal. Examples are Starbucks and BART.

It does not work with HTTPS. And we should encourage users to use HTTPS.
So if they are using Google over HTTPS and we have captive portal and
they want to open Google (what is what they do in practice first) over
HTTPS, you have two options:
- you block 443 (and all other ports) until they confirm
- you intercept and have some untrusted SSL shown (which is really bad
to get people used to that)
- you leave through all traffic before the captive portal, you intercept
only 80, but then it is very strange why everything works, except 80

There may be legal reasons why we'd need a splash page, so if that turns out to be the case we may have to block everything until they click "ok" to some agreement. We'll talk to lawyers to figure this out. Hopefully it's not required. If it turns out that we can get away with not having a "real captive portal" then we should just block port 80 and trick the tests that different devices do to figure out if they're behind a captive portal, such that people will see our splash page but with minimal limitation of their connectivity. We also talked about allowing people to say e.g. "don't show the splash page for this device for 1 week" and a way for more technical users to input the mac address of devices that should never have port 80 redirected.

In general captive portal is a very bad moment to display any
information. People want at that moment to connect to the Internet, they
will just click anything and continue. What you would want is to display
something after they finish working with anything. So like captive
portal people maybe read first time, but later on it is useless to use
it for some messages and notices.

Yes we know this, but since captive portal is the only way that that will allow us to tell users anything about the mesh then unfortunately it becomes our only solution. One other proposal was to have the ssid be a short url (which i think we should do either way), but i suspect very few will bother typing that in.

And the most important thing: If you have captive portal on nodes, then
every time you want to upgrade captive portal, you have to upgrade
nodes. (You could maybe make some system which syncs this automatically,
but then nodes are getting more and more complicated and you might want
that things are stable and don't change once they are deployed.)

We should definitely have a system for updating the captive portal page. We've been tossing around ideas about having the local community use it for geo-specific notices, or even having a few geo-specific unobtrusive ads from local businesses.

Captive portal also makes things harder when uplink to Internet fails.
So then in such situations people have to confirm the captive portal
just to be able to connect to the network, not even Internet. This is
hard to explain to people. This difference.

If the uplink to the internet fails, then the captive portal should tell people.

Captive portal makes it really hard for Batman roaming between nodes.

Why? You just have each node host the exact same page and whichever node you are connected to when you request your fist non-ssl site will give you a splash page.

So we removed captive portals from all nodes. Currently we don't have
anything. What we are planning is to intercept first request on port 80
on the Internet gateway and redirect to our social info portal called
PiplMesh:

http://dev.wlan-si.net/wiki/PiplMesh

So the idea is that people can still use the network and Internet
normally. You just hijack first request. But it is not a captive portal
(so no button to confirm to get access). Just to display information
about the network. But even more important: to display a portal which is
useful to people using the network. If you have such a portal, then
people will be using and reading things there and you will get people
engaged into the network and then you can communicate two-ways with your
users.

Great! We definitely want the splash page to be a gateway to community mesh services!

So the idea is that on that portal all connected people to the mesh can
communicate in real-time, share information (like "hey, this event is
happening there and there, come", or even "hay, I am sitting in this
coffee shop, anybody for a chat?" or "I am a CouchSurfer and got
stranded in the city, can anybody offer me a couch for a night?" And you
can share this based on the distance in hops from the node you are
connected to (for example the message about chat is relevant only to the
node you are on, the message about the event is maybe useful to more
people, and CouchSurfer might want to address the whole city). So the
portal again introduces the physical nature of "voice" into virtual
sharing. How load you are, so far you are heard. And distance is hops
between nodes.

Sounds very similar to ideas about decentralized social networks I've seen lately as well as some of our own projects. Is all of this implemented yet? It seems like something like this should be developed in a way that does not make it dependent on a mesh network, but instead allows it to operate well on any network, synchronously or asynchronously.

And next to that you can also display local relevant information for people.

So the idea is that captive portal influence is minimized (only 80 port,
firs time) and that the content of the portal is made useful to the
people. So that they might even use it outside the captive portal use.

Yes.

But yes, this is again possible because we have a centralized gateway
and we don't have issues with central services if the network can still
operate without them. They then just add a value to the network and make
adoption and usefulness of the network higher.

Why would you implement something like this as a centralized service? That seems lazy. Decentralized networks should run decentralized services.

(The development of PiplMesh sadly stopped and we will probably rewrite
it from the scratch. But the idea I believe is still valid.)

A good opportunity to write it as a decentralized service instead then.

Honestly the idea of having a community web app as a splash page occurred to us early on and we are well aware of the problems associated with captive portals. PiplMesh could have been interesting if it was a functioning and maintained piece of software.

Your experience with mesh networks and the software you have developed is of great interest and value to our mesh group!

However, it would be helpful in the future if you first ask and listen to find out which discussions we have already had and which solutions we have already arrived at and afterwards chime in with thoughts and considerations that have not occurred to us. This is the bay area. If a idea occurs to you, check with your network. Ten people will have almost identical ideas, two of them will be working on a related piece of software, and one will point out that there's already an app for that :)

Marc