Integrated Solutions

Looking at any networked solution, there are always the same base components that make the system: 

The user interface,
The communication layer API,
The backend (with interface),
Connection to your business (if applicable)

The Communications API and backend are our specialisation, having all components communicate in a way that is uniform  and well documented. This allows for other developers to to extend on the API Framework or connect new components  to the system.  

With Apple (*)OS applications we provide a native application as frontend to the system. Currently we only develop for the Apple product family, for which we also love to develop stand alone applications. Especially when they are connected via iCloud.

Our Javascript Application front- and -backends  are build in a modular way, reflecting the modules defined in the communications API. This transparent overlay allows for involvement of o ther developers in extending the framework.

Send us an e-mail to inquire how we can help you design your perfect platform.

Frontend:	Javascript App,	»
	native App	»
API:	HTTPS ReST API	»
Backend:	PHP Business logic,  data storage	»
External:	Connections to your platform.
B.Office:	Javascript App

Apple (*)OS Apps

« i.Solutions

We believe in the power of a native experience.

There is nothing that inspires more confidence than a rock-solid native application. There is epic beauty in clicking that icon and experiencing your app bloom to life in your favourite work environment.

We craft each and every app carefully, with a minimal everything approach, pouring in our love for minimalistic code and design. Combined with our modular mindset designing the application architecture, we believe we have a winning formula, offering a fast design - to product timeline.

We believe that inter-connectivity between devices is key in offering a satisfying customer experience. Back that up with a solid online app and we are convinced your customers will be back for more.

The power of having a native app as one of the front-ends to your platform guarantees customer engangement, as your application becomes part of their every day life.

We would love to contribute to an expanding macOS application base. We feel that the desktop environment is falling a bit behind when it comes to new applications that are being offered, and love to give that focus in the product development phase.

Send us an e-mail to inquire how we can help you bring your customers that native engangement.

OTPManager: Seamless Two-Factor Experience

OTPManager implements the industry standards developed by the Initiative for Open Authentication (OATH), and the HMAC based Time-based-One-Time-Password (TOTP) as specified in RFC 6238.

Our OTPManager was conceived in order to create a seamless Two-Factor Authentication experience. Until then, you needed your phone (which was always just out of reach somehow), in order to login with 2FA. With the OTPManager, you suddenly had your OTP Tokens under your fingertips on the desktop, at any moment.

Version 2.0 of the OTPManager features iCloud connected devices.

Version 1.0, released in late 2014, was a macOS only version, running on the desktop. With version 2.0, released in early 2021, OTPManager runs on all Apple devices, making use of the secure iCloud Keychain to distribute the tokens. This enables the user to have a convinient place to manage all 2FA tokens, with automatic propagation to all connected devices.

Go to the product page

We celebrate years of OTPManager

Our release of the OTPManager for the Mac on November 5th 2014, was the first Two-Factor Authenticator for the desktop.

There have been more than 260.000 installs of OTPManager. That is around 3.610 installs per month.

Server Side Applications

« i.Solutions

The Core Foundation of your Platform

Without the Server Side component, there is no internet application. The Server is the hub, the Core of your system, where all connections go to either get, update or put data.

All our projects start with defining the ReST API, the encrypted interface to and from the platform. With the design of the API in place, we can then develop the Core and the font- and back-end intefaces in parallel, reducing the development timeline.

Using a ReST Interface to the platform is the first step in scalability as there could be a cluster of servers at every endpoint (of the API) if needed, and is per definition suitable for caching and load-balancing.

We use PHP as our backend programming language with which we have more than 20 years of experience. PHP is well known in the web development community and this also allows for other programmers to extend or maintain the application, even after we have delivered your platform.

Send us an e-mail to inquire how we can start designing your platform.

Representational State Transfer (ReST) API

ReST is beautifully elegant. Consider this request to get all the products for a customer with id A1C908CE-170C-4479:

  GET https://api.company.com/customer/A1C908CE-170C-4479/products

The beauty of it is that all variables in the request (in this case the customer id) can be cached as the URI is static, even though the data is dynamic. The implementation details of the business-logic are hidden and there is no tight coupling between the data request and the implementation.

Scalability == Flexability

Maybe the endpoint /products is handled by a completely different server then the endpoint /account. You could have a certain endpoint transparently connect to a third party, you could even spread ranges of customers over different servers:

  /products -> server 10

  /account -> server 8

  /invoices -> api.3rdparty.com/yourID/customer/A1C9(...)9/invoices


  ID range 00000001 - 30000000 -> server 1

  ID range 30000001 - 60000000 -> server 2

  ...

Using ReST makes your application ready for the future, the possibilities are endless, and they can grow over time. For instance invoicing can be done by a third-party at first and then transfered in-house (or the other way around). The connections from the front-ends to the platform do not change, only the implementation changes.

Versionable

Consider you are in the process of upgrading the backend-code, maybe for the whole API or just one component, and you have at least one big user that is version-locked to the API.

In this scenario there are a few possibilities to mitigate that issue:
- version the whole api: https://api.company.com/v2.0/...
- version parts of the api: https://api.company.com/customer/v2.0/...
- send a http-header with the version you need: X-API-Version: 2.0

And then, if transparency is an issue, have the IP-Range for that client redirect to a different API version.

So with the ease of versioning, you can already implement the new version Alongside the current version, which is great for beta-testing. And again, you could redirect the new or beta version to completely different backend servers.

Implementation Abstraction

In older approaches to querying data as opposed to the ReSTfull way, it would translate to something like:

  /customer.php?id=A1C908CE-170C-4479&query=account

  Or /customer_account.php?customer_id=A1C908CE-170C-4479

  Or /api.php?customer_id=A1C908CE-170C-4479&query=account

From the Example above, it should be clear that everything is so tighty coupled with the structure of the backend-logic that caching and scalability is a real and big issue.

An other advantage as demonstrated above is that ReST doen't leak implementation details. It could very well be that the code that retrieves the data, actually calls the more archaic scripts as shown above, but there is no tight coupling with the backend implementation. This is amazing when considering upgrading the backend software, implementing caching layers, scaling and even have different applications (even redirected to third partys) handle different endpoints of the API.

Go ReST!

In short: we believe that the only way to go is ReST, even if it is just the customer database accessed by an intranet page and the database server is located in the broom-closet, second door on the left. You never know what the future entails... With a ReST based application, you are ready for everything.

Send us an e-mail to inquire how we can help you design a scalable and robust platform.

Secure sensitive data, secure all

In the olden days, the motto was "secure sensitive data", now a days it's more "secure all data". Datamining, extensive build-up profiles over time and A.I. have made us realise that in this day and age, we might consider that all data is sensitive.

This was never a problem for Backend applications and Native Apps, as those platforms have native encryption and decryption and key generation utilities. But what about the Browser? The Javascript code?

Web Crypto API

Thankfully there is the Web Cryptographic API, which make payload encryption beteen front- and back-end possible, natively in the browser. Now we can even pass encrypted database records directly to the Web-Application without the need to decrypt it on the server. Curious about the support in your browser? Here is a Live Browser Support Table

The Web Crypto API also makes Hybrid symmetric-asymmetric encryption possible between the browser and the server. The flow is normally:

  Client -> connects to               -> Server
  Client <-         sends public key  <- Server
  Client generates session key and signs it with the public key

  Client -> sends signed session key  -> Server
  Server decrypts sessionkey with private key

  Client <- data enc. with sessionkey <- Server

And from that point on, all data is encrypted with a symmetric key only valid for that one user-session. Something that was impossible before with a Javascrip only application.

What about HTTPS

But why would we need payload encryption when we are already communicating over an encrypted connection with HTTPS? That is a good question. Some implementations (for instance medical data) have the requirement that the data should be encrypted upto the point where the data is read.

Also think about the in-house portion of the platform. For instance, you can argue that customer data should always be encrypted, even in an intranet environment. With all that in place, the security portion of ISO certifcation should be a breeze.

Unfortunately there are still websites and applications that are not encrypted and served over HTTPS. But thankfully there are initiatives like Let's Encrypt which provide free SSL-Certificates with the goal to have the whole internet encrypted.

Payload signing

With the WebCryptoAPI we are now able to have the payload signed from every front-end to our platform. As stated before, native and server-apps where never a problem, only the browser stayed behind. Payload signing means that for all data that goes over the 'line' the whole payload gets a secure checksum so we are absolutely sure, when it arrives on the server, that the data has not been tampered with, or the request itself if we include header-signing.

Secure messaging / local storage

Now with every fron-end platform able to (a-) symmetricaly sign, encrypt and decrypt payloads, we are able to have for instance secure messaging between clients in a chat portion of the application, where not even the system-administrators are able to read the messages. Also what is logged on the server will only show the encryped data, not the plain text.

Full scale encryption support also means that we are able to have the encrypted messages, or payloads, or any kind of data, localy stored in encrypted and thus secure format, which any frontend can read. This includes the local data storage in the browser.

Send us an e-mail to inquire how we can start securing your platform.

Javascript Apps

« i.Solutions

Solid Web-Apps that work

For platform-frontends that connect to an ReST API, there is no other (good) choice than to build it in javascript. The Object-Oriented language, that evolved next to and with browsers was developed for the web. In 2019 Javascript was ranked the most commonly used programming language, with 67.8% of developers employing it.

The big advantage is that is runs client-side (in the browser), so there is no strain on the servers when rendering the application. Javascript and more importantly the introduction of Ajax made asynchronous requests common place, so we don't have to wait for the round-trip of a requests, and can keep using the application. And now with the wide-spread support of the Web Crypto API we have all the cryptographical power we need natively in the browser.

With all that awesomeness we now have native-browser-applications that can feel as solid as native apps. Further more, because of the structure of the language, we can overlay the javascript code transparently over the ReST API, what makes the web-app as scalable and flexible to develop as the back-end.

So there is the robustness of Javascript being a fully-fledged programming language, and the frivolity of an amazing animation framework, how can this not produce amazing apps.

Send us an e-mail to inquire how we can help you develop an amazing web experience.

Why?

The only cure to all this madness; is too dream, far and wide, if possibility doesn't knock, create a damn door. If the shoe doesn't fit, don't make it. If the journey your travelling seems to far fetched and wild beyond your imagination; continue on it, great things come to the risk takers. ― Nikki Rowe

History of the Founder

Who would have thought in 1995 that the world wide web would become the foundation of almost all interaction and communication between people. Well, here we are, and in today's landscape the internet is as much a part of our daily lives as water and food.

Personally, I discovered the power of 'the future' when dialling up to BBSs and communicating with people all over the world. I remember the moment I 'got' it. I was in a chatroom on the IRC and I was communicating in real-time with people that were on different continents! That was a big deal in that time (1993), because back then something 'simple' like placing a phone-call from Europe to the States was a hassle and sometimes even required a switchboard operator.

That moment, realising what we were actually doing, communicating real-time around the globe, changed my life. I dropped out of school, because my whole being realised that this was the future, and stared to learn about computers (building, repairing), networks (laying cable, hardware and software configuration), systems administration (installing and maintaining linux), graphic design for the web (and print) and finally programming. All focused on the marvel that was the internet.

So, yes, I am an oldSKool programmer. I don't like to drop in frameworks just to make a deadline. I think about the bytes in memory, the strain on the CPU, and try to find the balance between academic object structures and plain 'ol procedural code. I love to optimise, but not at the cost of code legibility. But yes, I am formed by the limitations of the early days when we had little memory, disk space, a 'slow' CPU and limited bandwidth, we had to make everything run smoothly under those conditions, and that has never left my system.

Personal recommendation:
TV-series about the 80s technological revolution: Halt and Catch Fire

Check out the (restored) First website ever

Tim Berners-Lee, the inventor of the World Wide Web