NLUUG: The Open Web
Posted Nov 5, 2009 5:22 UTC (Thu) by
drag (subscriber, #31333)
Parent article:
NLUUG: The Open Web
Total kick-ass stuff.
Normally I am not a big fan of the Web 2.0 rhetoric because of misplaced
commercial interests that continuously focuses on 'cloud computing' as a
way to scale proprietary web applications to a large enough scale that you
actually start having meaningful numbers.
But the reality is that the best way to scale everything is to effectively
have one node per user.
-------------------------
The major limitation in all of this is not so much usability as much as the
technical aspects of the implementation.
For example I have a friend that went through the time and expense of
purchasing internet access through a cable provider that only provides
private IP addresses. He can't run any services from his house. Not even
SSH access or anything.
Another example is that I've been playing around with SIP. SIP is great,
open, and has good performance. Security is a bit so-so, but other then
that I like it and there are lots of devices that support it.
But you know what happens if you have two people on the same private
network with NAT firewall and softphones? _it_won't_work_. One will not be
able to connect. Sure one will work fine, and if you went through the
trouble of setting up a SIP gateway or proxy or whatever then you could get
that working fine, but that is a huge PITA.
Meanwhile Skype seems to have dozens of ways to work around a firewall. You
can have multiple people on the same network doing the same protocol behind
a NAT firewall and it'll 'just work'.
That is why things like Ekiga and Empathy suck* compared to Skype. Skype
can just plow through any network, while SIP requires a smart person to
operate it and set up the tunnels or know how to find a proxy service or
whatever.
(*other then they are buggy and are not only difficult to configure that
they rarely can be configured in a way that works well.. while things like
linphone have a network configuration system that is massively easier to
work (even though the application itself has oddness and UI problems
typical with older Linux applications). For example I have a SIP account
that is dedicated for VoIP to POTS, but it does not support P2P. So I want
to use a Ekiga SIP account for P2P and a different SIP account for POTS.
Ekiga can only be configured to do one or the other.. if I set up a SIP
proxy it will send all traffic through it.. which is incompatible with
Ekiga's service, but required for VoIP to POTS. I can do that with
Linphonec just fine, but Ekiga it is very difficult to use. Empathy I can't
get to work with anything in Ubuntu 9.10. (which is compounded with Ubuntu
not being able to make a smart enough PulseAudio setup (but they are doing
much better with 9.10)))
So like Skype you need a way to plow through networks. Not just for VoIP or
one or two protocols... but with everything.
So I figure the best way is with IPv6. If you use typical tunnelling stuff
it is difficult to setup in a way that is universally accessable... that is
they are generally designed to create private secure networks and not
really designed to allow open penetration into private secure networks.
But if you use a IPv6 tunnel over IPv4 then that is designed to be
universally accessable through IPv6 networks. Not necessarily for VoIP... I
know the latency will kill performance. But the advantage of this approach
is that individual services and web APIs don't need to concern themselves
with details about circumventing NAT firewalls or blocked ports or
whatever... they can worry just about providing a nice optimized protocol
without the normal restrictions that you typically have to deal with. This
should make things massively simpler from a lower level network protocol
point of view.
-------------------
So then the challenge is to set it up in such a way that a user who has no
f-ing clue what SIP is or IPv6 is or anything else can just install a
simple application in a familiar manner and have it 'just work'.
So here is a possible solution:
User installs a Vmware player or Qemu VM as if it was a application on
their Windows/OSX/Ubuntu/etc box.
The VM has two network interfaces. A "private" network and a "public"
network.
The public network does IPv6 over IPv4 tunnel and can be accessed by
anybody on a IPv6 network. (Of course you have some heuristics that test to
see if a real IPv6 is accessable and if so use that if at all possible
instead of the tunnel)
The 'private' network interface is only accessible to the PC the VM is
running on. And then all the configuration and communication happens from
the user's browser to the private interface on the VM. That is the main
user interface; a web application.
So from the point of view from the user here is how it goes:
1. Sign up for the account (which would include a OpenID and access to the
required network services)
2. Download the application and installs it. The installer sets up a
bookmark in the browser and/or a icon on the desktop that starts up the VM
and launches the web browser with the correct address to access the web-
based user interface for the VM environment.
3. The user is then prompted for the OpenID details and keys or whatever,
which is then loaded into the VM, and then the VM enters 'go mode' and
begins providing all the services.
At no time is the user ever made aware of anything that happens or how it
happens. If they are curious they can read the documentation and get deeper
access to the VM, but that is purely optional.
The actual web-based application stuff in the VM should be done in a
similar way to Sugar. A standalone Python WSGI application (or similar high
level language with standalone web application capabilities) that can
access the open APIs or at least provide hooks into services or whatever.
Whatever Web 2.0-ish thing you want to accomplish. For most people that
should be enough. A stripped down Debian-style environment can run a low-
usage website with a 128-256MB of RAM allocated.
And it must be developed to be 'secure by default'. It should be
exceptionally difficult to make the VM insecure.
If users desire better performance or more capabilities they can upgrade to
the 'home server' type of thing were they purchase a standalone hardware
that is more capable... like using more WSGI python processes sitting
behind a Apache-based reverse proxy and that sort of thing. That way if
users desire to have LOTS of communication and LOTS of friends they can set
up something that will scale well.
And you can have additional services that you can't really get in a
resource-strapped VM.. like firewall/router and NAS services.
Since dedicated NASes these days are doing more and more and more in order
to make their product stand out then there should be a big market for NAS
OEMs to exploit to attract customers. That way you would not have to make
a big production about setting up a server. You have the open source
applications bundled with NAS firwmare upgrades or something like that.
And then you can use this also to promote wider adoption of IPv6 and reduce
dependence on IPv4 firewalls. Tell users that if their ISPs supported
something called 'IPv6' then they could get much better performance and
higher levels of security.
But on private networks it should be a IT admin's worse nightmare. It
should implement every trick under the book to get that IPv6 tunnel out in
the world. Tunneling over TCP on port 443, for example, can easily
circumvent many of the most restrictive firewall restrictions. Hell, even
running in degraded mode by tunneling over DNS should be attempted! By
making it exceptionally difficult to stop, you make it very easy to get
working.
(
Log in to post comments)
