Ted Smith typeth: | ...is because we seem to have a consensus on what UIs are necessary - a | PHP-based web UI would be nice for users who don't want to install | things, and a desktop client would be nice for users who do.
It is I who has started doubting the validity of the commodity webhosting approach, not because I don't like cheap server space but because of your remark about scrapping private keys off virtual machine memory. It sharpened my doubts about VM technology into realizing how this can be just as dangerous as giving your data to Facebook. ISPs can easily be subpoenad into monitoring the virtual machine of any activist group or whoever is to run GNU Social, even if we design the system to use plenty of HTTP-based cryptography. I was further alerted by RMS's words on SaaS. Most of them apply to our constellation, even if he thinks social computing should be exempted. I am not fundamentally against web-based implementations, in fact I started out in this discussion thinking that a Facebook-like UI would be pretty cute to have, but I feel it should be combined with a license that goes beyond the Affero GPL. It should be forbidden to run this software in virtual machines as the privacy of the users can no longer be secured. If you run the software on your own hardware server, even if it's in somebody else's rack, it is much harder to harvest. Maybe I'm just some five years early thinking about the dangers of VM computing, but that's traditionally my role hurrying ahead of time. Concerning web interfaces as such.. I know well how powerful they have become and wouldn't be surprised if desktop interfaces were WebKit-based or similar. I would consider it a great move if we found a way to share HTML/JS or other web-oriented logic between a desktop and a web server implementation, so that the UI is fundamentally the same whether you run it locally or not. Concerning the protocol it still hurts to think it could be "web hook" based, but it could indeed be designed to be transport agnostic and run on several transports. I do however think it would be a good idea not to limit ourselves to round-robin distribution but to provide distribution trees. That means multicast structures on top of whatever is used.. be it HTTP or plain TCP/UDP. I can imagine designing a library for transport agnostic multicast, which allows distribution trees to use a hybrid of HTTP and plain networking. Another point of critique against server-based social networking is the power of the user's private key: User-bound end-to-end and one-to-many encryption are a whole new dimension of privacy within social exchange and it's a pity if we don't leverage that just because we have a requirement to run on commodity web hosting. So in that sense having to be able to provide a web frontend seriously limits the possibilities where this technology could head off to. -- ___ psyc://psyced.org/~lynX ___ irc://psyced.org/welcome ___ ___ xmpp:[email protected] ____ https://psyced.org/PSYC/ _____
