Our project has two inter-dependant components, both of which are vital to each other. The web application is a business case that we have identified as having immense potential but one that fails because for lack of an effective user trust model. The trust application solves this problem but cannot be built without a use case to build it around and demonstrate its viability. This puts us in the enviable position of having two excellent products for the price of one!

However they will only be excellent if we choose the right technology stack…

It also means we will produce two separate applications – The Buccaneer Network and, for want of a better name, the trust machine. We might call this “Trust Pilot” as that also has a nautical theme…

The Buccaneer application will be built using the popular AngularJS framework. The reasoning behind this choice is discussed here. The trust machine was originally conceived as a software package that could be supplied to application developers, but it was quickly realised that this approach has disadvantages:

• Supplying an executable application runs the risk of reverse engineering and exposing the business logic, making the product less secure.
• Supplying and supporting a distributed application is much more costly and time consuming.
• A distributed application have less access to user data to build trust metrics, as it will be isolated in its host application. A centralised application running as a web service would be able to gather data about individual users across a network of applications and build a more complete picture of the trustworthiness of an individual.

…so the plan is to make the trust machine a web service. Whilst there are advantages, this also presents certain problems:

• The service will access and process highly sensitive information. Any security breach would be catastrophic.
• The trust rating will be important to users. The way in which trust is calculated could be highly controversial.
• We believe the application has numerous business use cases and will be a popular service.
• As it will be a single API the application will need to be scalable.
• The trust service will be mission critical for many users. It will need to be robust.
• Not all use cases will be identical and trust is often context specific (link) so it is likely some degree of configurability will be required.