Extensions to Resonance

This section covers a few ways that resonance can be utilized to further improve the user experience. Each topic has a list of issues with the current method, and how it can be mixed with resonance to improve security or usability.

Internal service Extension interface

This interface could allow actions to be performed automatically on a resonance action, such as synchronizing files in a set directory with a user, telling your ftp client to reconnect to them to finish downloading a document, etc. This would require a new infrastructure to allow programs to tell resonance things it should do when it identifies a service. This interface would perform in a similar way to task scheduling programs, such as cron, however, would perform actions based on activities occurring with resonance, instead of on timed events. The implementation of such a system would be easy to program, but would have large implications for users. In some ways, this can be more thought of as a plugin system then a task schedular.

To keep the system safe however, an example of a security feature which would be needed to protect users from plugin based viruses includes the introduction of digital signatures on all the various modules to validate that the plugin belongs to who it claims. Users should be able to easily add modules, and just as easily remove them.

A realistic real-world example of a system which could benefit off an extension interface is VOIP (Voice over IP), a system which allows phone calls over the internet. By automatically adding other voip contacts from your roster into your VOIP program, it suddenly dramatically extends the use of VOIP in the real world, as users no longer need to manually manage their contact lists, instead having it created for them, full of the users who they are familiar with. This could be extended to any concept, and any programs contacts could match that of the ones on your jabber list. On operating systems with a central address book, resonance could ensure every online friend in your address book has completely up to date details.

Service Subscription and Notification interface

The aim of this system would be to allow users to subscribe to types of services they enjoy, so if they are started by someone, they are notified. The notification system would have to employ the use of plugins to permit Resonance to have different types of notification systems (as some people find some types annoying), and some examples of means which resonance could use to inform the user is as email, IM message, or box popping up, as shown below :

An interface like this would be especially helpful to users who like to have a bit of variety in the servers they join.

Dynamic Firewalling

Issues with current Firewall configuration for servers

RST issues with current firewalls in home usage

The main purpose of ignoring connections made by people, instead of sending back RST messages (which lets the computer know the port is inaccessible) is mainly to make the computer appear invisible on the internet, and make the people trying to connect believe that their computer isn't online. However, in the case that they are on the users resonance roster list and have been given permission to use a service, ignoring their connections instead of telling them the port is closed is pointless for reasons other then to reduce the chances they can determine the details of the machine, and to slow down the rate at which they can probe them for services, which again is pointless on a proper firewall.

If no services are running however, its often a good idea to ignore all connections by any user, as there is no reason why they should be connecting at all. In the case that they have been given permission to access a service by the server admin, all other ports should be set to block connections instead of ignore them for that specific user, as it prevents them having to wait for timeouts if they accidently connect to the service on the wrong port (such as the default port). Be aware however, that this should only apply to friends. People not on the friends list, who are connecting anonymously should always have their packets dropped when connecting to bad ports, as it slows down the rate at which they can find information, which may allow them to break into the computer.

Port redirection for daemons which dynamically change port

On a large server, where many minor services could be running and grabbing at different ports, things become difficult to manage, because if a service crashes, another might assume control of that port, and previous users might think their server went offline.

One way to manage this is to remember a users friends who were connecting to a server recently before the port changed, and redirect them to the new port. While this is difficult to do on larger servers, on smaller servers, and particularly game servers for instance, it is better because its rare for home users to run game servers continuously for a long time, and a few gaming servers change port every time the service is restarted, so redirecting the ports just makes it much easier for other users to access the server.

A resonance based Firewall solution

Resonance could be improved by integrating it with a firewall that sets permissions on a per user basis, and in a way that you can set whether only friends can access the service, if everyone can, or if nobody can. The best way to understand this process is by understanding the current firewalls. A diagram explaining this is below:

As you can see, if there is a fault in the service that allows its users to compromise the system, everyone can access the service, proving that the current system isn't very good.

Setting all of the services which you would allow your friends to access, to allow only friends through is a very good solution, as unless you have hackers on your instant messaging roster and weren't doing per-IP blocking (which is a major hassle) before, it would be much harder to hack the system then the current "open to all policy", and wouldn't require any added hassle. An example of a successful connection based on resonance is below:

This image shows how a friend would connect and be allowed through. Below is an example of a common hacking scenario which often occurs:

As you can see, as the hacker isn't a friend, he isn't allowed through, however, other users are allowed through still just as easily (provided they all have resonance, otherwise the user is prompted for each user to let through).

Native Peer to peer file sharing

One feature which resonance allows is easy to perform file sharing with friends. Because of its service sharing design, it can just as easily share remotely accessible drives which are opened by applications included with the operating system. This allows friends to access other friends files without the need for specialized file sharing tools. To get an idea of how this would work, say for instance, you wanted to share a bunch of documents to friends. The process would involve first putting all the documents in the guest/dropbox directory, enabling anonymous sharing for that directory and next, allow resonance to share it (preferably only to friends). Now, friends who want to access it would just have to select that service on their system, and provided their operating system is decent, it could automatically make it a drive on the computer, thus allowing technologies like Beagle, Spotlight, and Google desktop search to index it, making file sharing easier.

By introducing extra plugins to the system, and sharing the plugin with your friends, when such a file sharing service is started, resonance could be set to automatically mount every remote share as a drive, allowing almost flawless integration of peer to peer equivilent sharing into the operating system, using existing technologies, preventing the need for other software to perform file sharing. In fact, a group of friends could even set one computer as a central repository and use a plugin to set all their computers to send all their documents to the server automatically, and synchronising their document directory with it, so that everyone has up to date documents.

One interesting thing to note, is that this concept is no less secure then current peer to peer based filesharing systems (provided the file server system is secure), and since it is only with immediate friends, if you accidently share personal files, at least it is only to your friends, instead of to an entire internet full of people who are more likely to abuse the information.

Friendly DNS

One new innovation that resonance could allow is a friendly DNS system, which means that everyone on your jabber/IM roster is given their own virtual hunan-readable address which exists only on the users computer and is invisible to everyone else. This would mostly benefit programs which do not support resonance yet, because they could just use the virtual DNS address, which might look something like "andrewL.jabberserver.com.res" instead of having to use a users IP.

Handlers could also be set to allow much easier access to anonymous services posted on websites, such as doing "jabber://gameserver.username.org.au", so that even if your webbrowser for instance doesn't support the service type (generally they only support webpages and ftp), with jabber, it could be just forwarded to the jabber handler, which would activate the correct program (only after prompting the user of course first though).

Decentralised Peer sharing

This is one area which resonance could truly benefit. Most decentralised systems work by passing a list of nodes (which are computers known to use the network) to others, merging a copy of their node lists with their own, and then continuing, synchronising them, etc. Basically, each computer just tries to keep a list of all known network users. A diagram which shows an example of how a decentralised network would expand is:

One thing with these systems is the more random the nodes gained are, the better the system, as it is very common for users to start to develop similar node lists, as they all tend to grab the "seed list", which is a list of computers known to use the network shared by the owner of the network, so that starting users have something to connect to. However, the seed lists dont always contain every node, and if many users are starting off on the network, these nodes quickly become very congested and slow down. The fastest nodes on the network may also be unknown to the machine the seed nodes were obtained from, so the system obviously isn't always optimal.

By properly employing resonance in a decentralised system, the seeding process can be done on the resonance/jabber network instead of a single centralised web server allowing the system more opportunities for optimisation. Since resonance is based on jabber, which is decentralised though, it would mean that even the seeding process could be decentralised too.

In such a scenario where resonance performs seeding too, every resonance-supported computer can extend the network to known friends computers. In fact, it could even be possible to not download any initial seed list, instead establishing a decentralised network entirely through adding friends onto your resonance roster, causing it to grow. Because of Resonance, you can finally expect truly decentralised systems to be released on the market, without any centralised seed lists, thus causing them to run faster. A diagram showing the process of using resonance to extend a decentralised network is: