I think a frontend DNS/HTTPS service is pretty important for easy
adoption. For the following reasons:
- Need to provision a domain name without having the user jump through
DNS configuration hoops (unless they want to jump through those
hoops). The end-user's app should negotiate this through a defined API.
- Same goes for an TLS/SSL certificate. Would be good to acquire a CA
certificate for a few attractive domains, and then generate free
certificates under those domains for the end-users under API control.
- As you say, firewall traversal is needed as well.
As to to the IP <-> TLS certificate issue - that's done already:
http://en.wikipedia.org/wiki/Server_Name_Indication . However, seems
like there's a support issue under XP with IE and Chrome. Maybe one
can live with that - encourage people to use Firefox.
You could handle TLS on the DynHttpd side with a wildcard, but then you
lose privacy to the provider.
Bjarni Rúnar Einarsson wrote:
Hello GNU-Social :-)
I've been watching with keen interest the activity in the
free/open-social space over the past few weeks, finally got around to
subscribing to your list. I've got an idea kicking around in my head
(and a basic design), which might or might not be useful. Considering
that I have considerably more ideas than I have time, I figured I'd try
to start a discussion before spending much more time on it.
Would it be useful for the various open-social projects if there were a
cloud-based dynamic HTTP-front-end service?
This would be similar to DynDns, except instead of pointing your DNS
records at your current IP, which may be firewalled, it would create a
tunnel from your machine to an in-the-cloud reverse HTTP proxy, so a
locally running HTTPD on your machine can serve requests to the general
internet. Combined with a dynamic DNS solution, this would allow you
to run your social web-app (or whatever else) on your own hardware, no
matter how many firewalls are in your way and no matter how much you
move around.
Behavior when you aren't online is a fun topic: it could be anything
from a dropped request, to a 'Sorry, I'm not online now' page, to
automatic failover to a mirror on a friend's machine.
Doing this for clear-text HTTP is very possible, for HTTPS this is
pretty hard to do without running out of IP-addresses. So an 'open
social' web using a system like this would sacrifice over-the-wire
encryption and authentication, but instead gain total local control
over your software stack (aside from the proxies, of course).
I don't know if that is an appealing trade-off for anyone... but man I
wish someone would fix SSL so it wasn't 1:1 with IP addresses. Is
anyone working on that?
(The idea I am toying with is quite a bit more convoluted, where the
HTTP-front-ends themselves are a dynamic p2p network and the network
supports mirroring and fail-over for static content - but if the basic
functionality isn't interesting then there is little point in me typing
all day.)
Thoughts? Oh, also - does this already exist? :-)
--
Bjarni Rúnar Einarsson
address@hidden
http://bre.klaki.net/
Use http://bre.klaki.net/bre/contact.shtml
to bypass my spam filters.
.oOo.oOo. PGP: 02764305, B7A3AB89 .oOo.oOo.
--
Miron Cuperman
http://hyper.to/blog/link/category/the-new-web/reputations/
http://groups.fsf.org/wiki/User:Miron2
|