Current definitions of Web 3.0 seem to focus (at best) on the type of applications we will be seeing and what sort of uses the Internet will be put to in this phase of it's life-cycle. Discarding that for the moment, my interest is in what Web 3.0 means in terms of the technologies that will be used and the user experience they imply.
My Way ...
So, my take on Web 3.0 from a technology perspective;
- Two-way communication, to be realistic the concept of a GET command that repeatedly performs a one-shot transaction is a little, well, antiquated. Users have moved past just getting information from the Internet, they want to Interact with it, and it's very difficult to Interact with something when traffic initiation is designed to go in only one direction.
- Secure connections everywhere, given the level of hacking and government surveillance the concept of a clear text channel, well, again it harps back to the days when you could be anonymous because there was a lot of traffic and nobody could read it all. Those days are gone, and with the advent of new organisations like LetsEncrypt, who offer free SSL certificates, ignoring performance issues just for a second (I'll come back to this) there really is no excuse not to encrypt everything.
- Last but not least, Polyglot applications. Traditionally applications might be written in C, C++, PHP, Python, Java, or .. the list is long, the problem being that once you start developing an application and choose a language, you're pretty much tied to it and are forced to draw skillsets from a pre-defined pool. Not always a great idea, as companies still trying to maintain COBOL applications have found. Skillsets in the marketplace change and trying to get COBOL programmers (for example) at the moment, you're probably going to pay in excess of £1000 per day. So, the next generation of applications need to be able to draw on code written in a number of different languages, so not only can programmers with different language skillsets interact, but the language of choice for an application can develop over time as the product evolves and available skillsets change.
Ok, so there will be more, but those are the key issues that have been playing on my mind, and this is my first application that ticks all of the above boxes, screencasts available on YouTube.
Coming back to the SSL/performance issue, I've always been resistant to implementing SSL for sites that don't provide a login, simply because the overhead of running SSL makes sites vulnerable to DDOS attacks. This issue however is related to HTTP/GET and not really an issue for my vision / implementation of Web3.0 - so now we love SSL for everything. (yes, the free certificates help too!)
Incidentally, traditional web servers (Apache, NGINX, Lighttpd etc..) were all designed to process HTTP, if we're not going to use HTTP, that sort of obsoletes such software. So "no", the software demonstrated above does not use a traditional / recognised web server, and you maybe further shocked to learn the alternative doesn't suffer from the same loading and performance problems that plague applications like Apache. You know that old problem that Apache hits at around 25,000 connections per second, yeah? .. No, not any more, add at least a zero .. :)