I think a frontend DNS/HTTPS service is pretty important for easy
adoption. For the following reasons:
OK, thatś 2 votes 'yes', 1 vote 'scary' ;-)
- 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.
To limit the scope of the project I would probably ignore the above issues at first - neither of them really need to be part of a DynHttpd, or a dynamic DNS system either.
But yes, obviously making that stuff easy is important, and having a way to let people take part without requiring they have their own IP and/or know how to drill holes in their Firewall is what I'm talking about.
- As you say, firewall traversal is needed as well.
I am quite excited about the possibilities of running software on my own machine, in the context of a social web-based network. Having direct access to my complete digital library is exciting for sharing, and an app running on my laptop can do UI things which are still very hard to do on the web.
I understand that other protocols may be better for a new social network (such as XMPP or psyc), but if my parents have to install software to interact with me, then as far as I'm concerned the project is a non-starter.
You could handle TLS on the DynHttpd side with a wildcard, but then you
lose privacy to the provider.
It also builds assumptions about domains into the server, and requires every front-end server (why should a user have just one?) have all the keys. Neither of which appeal to me.
Thanks for the feedback, I am encouraged. :-)