EnThinnai Blog

In the previous post, we analyzed the preferred characteristics of addressing and ID in a user-centric messaging system. Also we saw the downsides of bilateral federation. We will use those principles to design addressing and ID schemes for a WebRTC-based messaging system.

Let us recap the conclusion of the previous post:

1. For all the obvious advantages of unfettered federation, bilateral federation fraught with undesirable downsides. It favors big and established systems and snuffs out any new proposed systems however user-centric they are.
2. Though bilateral federation should not be a requirement, it is preferable that a system give access to non-registered users (“guest access”) albeit it is a restricted access. The system is free to define the limits of the restriction.
3. It is preferable to separate the address and authenticator.
4. The address must be portable from one system to another.
5. It is preferable that a system must be willing to accept third party authenticators.

Addressing
Since the messaging system is based on WebRTC, it is reasonable to use browsers as clients. This suggests that WebRTC-based systems will be better off to use URLs for addressing. As simple as that. But a moment of further analysis would suggest additional benefits of this simple choice. One can make a few quick observations: namespace is the same as that of URL; no need for SRV/NAPTR record assignments. A little reflection would suggest that users can use URLs derived from their own Domain names and then forward them to the URL provided by their service providers. This way they are free to switch the service providers but still maintain the same address. In other words, there is no need for portability agreements among the service-providers.

But there is one big advantage that is not available to any other addressing schemes. A user can have infinitely many addresses and use them to convey the context of the session. For example, a system could allow a user to add parameters to the base address and associate business logic to those parameters. Consider the scenario where A would like B to review a document and provide feedback. In this case, the parameter could indicate the URL of the document and A could include the parametrized address in the email to B. This way both sides can pull up the document when the session was launched.

Next, let us consider the case of incoming marketing. The marketing website can place a click to call link that is indeed a parametrized address where the parameter links to the caller’s browsing history of the site. This way, a marketing representative can access the caller’s browsing history while answering the prospective customer.

These are only illustrative examples. One can easily imagine many others. The beauty is there is no need to standardize any of them and no need to reach a broad agreement before using them.

ID
As we observed in the previous post, the caller could be an unregistered user and so will not have an “address”. At the same time it is preferable if the caller could be authenticated before the session is completed. So we have to come up with an alternate ID scheme. Since we are designing a messaging system based on WebRTC, any HTTP-based authentication scheme like OpenID, OpenID Connect, indieauth or Single Sign On schemes would be preferable. If nothing else, the caller’s email id which is verified by sending a one-time password will also work.

There may be use cases (as identified by the called user) where there is no need to authenticate the caller. In those cases the server could skip the authentication step. Whatever the use case may be, user-centric ID is the order of the day.

Federation
The choice of URL for addressing and allowing the caller to directly connect to the called user’s server and use of user-centric ID and third-party authentication scheme make bilateral federation unnecessary. “Federation” becomes a unilateral decision made by the called user and their server. Furthermore this decision is temporal, and can be made and unmade at any time and without involving any external entity.

Current Implementations
Almost all of the contemporary video conference services use URLs as the address for specific conferences and allow “guest access” who are not registered users. This works for those guests who use a browser. This leaves out those who use conference rooms that conform to other services. To address this issue, many are reaching pairwise agreements so their conference systems will work with each other systems. But as far as I know none of them use it any further. No service offers to present the documents relevant for the conference. Nor do they use user-centric ID to authenticate callers before adding them to the conference.

Messaging apps like Google Duo and Facebook Messenger continue to operate in the old mindset. They still think the market is won by bulking up and holding users captive. Users are addressed by system-specific ID. They do allow “guest access”, but only after the calling user is cajoled and accosted to download their app. The ultimate aim seems to have the bragging rights to the largest installed base.

EnThinnai
The design objective of EnThinnai is single users must be able to host their own messaging system without losing any of the functionality and features available in large systems.To meet this objective, we do not have any choice but to use the ideas suggested in this post. We use URLs for addressing; we add parameters to invoke additional business logic. We use Indieauth as an ID and authentication scheme. If a user does not have such an ID, we generate one using their email ID. Contact/buddy list doubles as a whitelist of people who are allowed to call in obviating the need for bilateral federation. If a contact has an URL to initiate a session, then the user can initiate a session from the Contact list. EnThinnai is a showcase for what can be done with WebRTC that benefits the users. After all we developed the principles of webRTC for this specific purpose a full two years before Google announced their plans.

We are familiar with communication systems like PSTN, email, VoIP and XMPP; especially the importance, ney, necessity of such constructs like Federation, ID and Namespace. But WebRTC is fundamentally different in comparison to these other systems and so we can come up with different approaches that ultimately benefit the end-users, even if the service provider landscape is fundamentally changed. So it is instructive to review these constructs and apply them to a messaging system based on WebRTC.

Federation
Thus far, autonomous systems agreed to federate among themselves to provide global coverage. For example, PSTN providers interconnect among themselves so a user from a provider can call a friend who is served by another provider. This agreement to federate is universal and long standing. We fully expect it to be working and it breaks only for geopolitical reasons. A similar situation exists for email systems, though providers are occasionally blackballed if they are lenient in controlling spammers. The ostracization is total and complete and is used as a punitive scheme. These two cases set us our expectations for other systems and federation became a holy grail for all new systems.

But VoIP faced practical difficulties. Initially there were competing protocols. Even when SIP eclipsed H.323, there were difficulties because new versions were coming out too quickly and systems adopted them at differing rates. So SIP providers settled for federating as PSTN providers. This inhibited many features that could be offered by SIP and users have to settle for what could be done by SS7. By the time XMPP rolled in, providers’ mentality changed even as end-users clung to the romantic notion of universal federation. Winner take all became a business tactic. Though an easy federation is built into XMPP, individual providers refused to federate. Let me stipulate that for all practical purposes, XMPP systems are islands.

To a certain extent, there are valid reasons for not to federate unconditionally. Consider two enterprises A and B that would like to federate because they are collaborating on a project. With the current construct, all the employees of A are federated with all the employees of B. This includes open sharing of some sensitive information like Presence. So B’s server will know the Presence of the CEO of A and there is no control on how B’s server further disseminates this information.

The upshot of this is that even though federation is a laudable objective, there are technical and social issues that have stymied previous systems. The main culprit is that federation requires bilateral agreement and it is total. It is much preferable that federation is done at a more granular level.

ID and Namespace
All the prior systems (PSTN, email, SIP, XMPP) use IDs for dual purposes. ID is used to locate the other end of the session (let us call it addressing) as well as identifying the originator of the session (let us call it authenticator). So a non-user may have an authenticator, but will not have an address.

It is preferable that we decouple these two. For one, a system could allow even a non-user to originate a session to one of its users, thereby blunting the force of “federation hammer”. Additionally the initiating user can select use-appropriate ID; employer provided ID for work related sessions; a personal ID for social occasions and the like.

Namespace stipulates the format and constraints for the ID. For example, PSTN’s namespace is defined in E.164 Recommendation. XMPP, SIP-based VoIP and email have more or less similar format – composed of username and the domain name. A recognized downside of these structures is that the ID is not portable. (Through regulatory fiat, phone numbers are portable within a country,but not universally.)

Even though SIP-based VoIP got wider adoption, there was enormous pressure to federate with PSTN. This forced SIP-based systems to adopt E.164 for addressing. This prompted a movement to map E.164 addresses to one that can be used in the Internet domain. This gave rise to what is known as ENUM Recommendation. In short, the recommendation suggested to exploit the hierarchical structure of E.164 address and map it to hierarchically structured subdomain under a well recognized first level domain – e164.arpa. For a while it was all the rage because one could replicate many of the Intelligent Network services available in the PSTN world in VoIP world. (This is when many were celebrating the Stupid Network.) For our purposes, it is noteworthy because in a limited way it pointed out there are advantages in separating addressing from the authenticator.

Directory service
To this day I get confused whenever I hear this phrase because I imagine the Telephone directory/411 service telephone operators used to offer which gave a person’s address. But it refers to something altogether. Given a SIP URI, Jabber ID or ENUM address how to further concretely locate the entity that can further process the request. This is very much similar to how the browser retrieves A or AAAA record when it tries to access a URL. Both SIP URI and Jabber ID use SRV records. ENUM utilizes NAPTR and SRV records in succession.

It is important to note how Directory service is done because it points out that if a user would like to port their address and/or authenticator, the older domain has to play along. But there is no motivation or regulatory requirement that they do.

Summary
As we attempt to design a system based on WebRTC technology, let us summarize what we have observed thus far:

1. For all the obvious advantages of unfettered federation, bilateral federation is fraught with undesirable downsides. It favors big and established systems and they could snuff out new proposed systems however user-centric they may be.
2. Though bilateral federation should not be a requirement, it is preferable that a system give access to non-registered users (“guest access”) albeit it is a restricted access. The system is free to define the limits of the restriction.
3. It is preferable to separate the address and authenticator.
4. The address must be portable from one system to another.
5. It is preferable that a system must be willing to accept third party authenticators.

In the following post we will suggest a way to incorporate these points and suggest an addressing and authenticator scheme that is user-centric and at the same time does not place a new/smaller place at a disadvantageous position. We will also point out additional benefits of the proposed scheme.

Zoom is the current darling when it comes to conferencing service. Consequently, many have attempted to find out the secret to their success. Both by people technically knowledgeable as well as general users. This review that appears in Inc is one of the latest.

It lists three points that distinguishes Zoom from others:

1. You don’t have to download anything or sign up for anything
2. You can see everyone
3. Test computer audio

But these are not unique to Zoom. Actually they are somewhat misleading. It is still a mystery to me as to why they are successful. Let me take each item and elaborate.

You don’t have to download anything or sign up for anything
It is not really correct that there is no need to download anything or sign up for anything. If you are a host of a meeting, you need to be a registered user. And it asks me to install an extension in my browser. On the other hand, any service based WebRTC will not require installation of any extension. Sign up is strictly an administrative matter. There are services that do not require registration. Not requiring any downloads for guests is the direct result of WebRTC and not unique to Zoom – if anything they are Johnny come lately.

You can see everyone
Over the years VC systems have tried different screen layouts. Depending on the use case, one scheme may be more appropriate than others. In a collegial setting where it is norm for multiple people to speak at once or people recreating a music concert, gallery view is preferable; but speaker view may be more appropriate for a webinar with a question and answer period. For a working meeting among a well established team members, the facial video is only incidental; what is more critical is the shared screen. This suggests a screen layout used by around.co

Test computer audio
Many VC systems go through a preview step where you can check that local audio/video works fine. I don’t think it is unique to Zoom. Some even check current network conditions by measuring delay and jitter. I am not sure what is to be gained with this initial check? More often than not the network congestion is transient; the initial condition is no indication of what will happen during the call. The one thing it will catch is how good is the local network; since most of us use a WiFi connection this may be useful.

All in all, it is clear that Zoom is a popular service and we need to explore why it is so. But the three items listed by this reviewer can not be the reasons.

EnThinnai is a 1:1 messaging system focused on security, privacy, data ownership and data portability. Lots of care and thought has gone in to the design. This post lists some of them.

Hosted in a dedicated VPS host

Each customer or a practice is hosted in a dedicated, managed server instance. This ensures that customer data is isolated from those of others. Also this setup allows easy migration if it is desired. You are not locked in. We have to earn your business every month with our service and features.

Bring your own domain and ID

Your friends and clients can reach you by clicking on a URL you had previously shared. This URL depends on the domain name of the server and your ID. This the case in many other applications. For example, your email id changes if you change the provider. Historically this has been a deterrent for people to move. To counter that, we allow you to bring your own id as long as it follows a structure. Additionally, if you own a domain name (or a subdomain), we can set up the instance to use that instead of one of our own. There is no additional charge for this, though the industry standard is to charge a premium. We have to include this in the base package since we truly believe that you must be free to move at any time you want and nothing in our design should be an impediment.

Free Guest access to your friends and clients

Most of the systems allow free access to your friends and clients so they can all you. But they do not authenticate the callers. The whole system is built on the premise that few people will know the URL your caller will be using to call you. And then subsequently, these system depends on the assumption that you will be able to identify and validate the person once the session starts. In contrast to this, our system will allow the caller to authenticate themselves by sending a one-time password to their email. We also recognize that there are occasions when you would want any second party to reach out to you as when a prospective customer wants to reach out to you. This flexibility is unique to our system.

Data ownership

In the course of operation, the system stores information related to registered users. For example, the system will store a list of friends who are allowed to initiate a session with the user.  Users can save their contact information and share them with their friends. The system stores session information for later review. All these are collected and stored just for the benefit of the individual users. Also, the users can port their data out of the system and use it in a different server.

Privacy and security designed-in

 The system is designed with privacy and security built-in. Even though the main purpose of the app is to share information with others and to allow others to call the users, it uses what is generally known as “Default Deny” philosophy. The app allows the users to share their Availability status and profile/contact information. But, the user has to specify who can access which information. And you can change the permission setting at any time. This granular control to access is unique. The same goes for who can initiate a session with you; even then which mode – text, voice, video – is up to you.

No additional programming required

This app is designed so it can be used by consumers directly. So there is no SDK to master or any need for further programming. Still, the app offers great flexibility and can be used in different scenarios and configurations. For example, one of the use cases is its use in customer support. For this use case, the app will display to your callers their position in the queue. Instead of otherwise engaging the caller while they are waiting (or being held), callers are free to attend to other things; the agent will buzz the caller when it is their turn. All this is pre-programmed. Other use cases already designed are Pet monitor (caller can hear/see audio/video of the pet and not the other way around), Baby monitor (both the caller and the baby can hear/see other’s audio/video) and Door monitor (you can see hear/see the audio/video from the door, but the visitor can only hear your audio). All this you select simply from your dashboard and will be encoded as part of the URL you will share with the prospective caller.

Multiple concurrent sessions

Nominally, all sessions begin when the caller sends a text message to you and the session takes place in an independent browser window. At any time after that both the parties agree to escalate the session to an audio or video session. The system allows you to have multiple active sessions. Either party can close the media portion without closing the session.

Given this structure, you can have multiple active sessions; presumably you are using audio/video in only one session even though the system does not force it. 

EnThinnai messaging app is a good fit for Nonprofits focused on counseling outreach services. It offers strong security and privacy features.

We offer managed, single tenant instances at a very low price. All the data is owned by you and not shared with anybody else. And it is totally portable. It can be parked at any domain name of your choice. So it can be obscure, distinct and unassociated from your main domain name. This will be useful if somebody happens to walk in on your client’s side. Also, by using your own domain name you are free to replace EnThinnai with another WebRTC-based app and still keep the previously shared WebRTC call URLs working. No lockin; no long term contract. Your cost will be dependent on the number of counselors and NOT on the number of patients you will be supporting.

Your clients need not register to use the app; neither do they need to install an app – they just need a recent version of a browser. If they use the browser in incognito/private mode, no tracking information is retained in the client’s device. In the event of unwanted intrusion during a chat session, the client can exit off the session quickly with no visible trace. But the counselor will be notified of the Quick Exit, so the counselor can summon help. (This feature is under development and will be available shortly.)

Give the ones you love wings to fly, roots to come back and reasons to stay – Dalai Lama

Wings – Data portability, Bring your own Domain Name; Reasons to stay – Low cost and is independent of number of clients; portability with no downtime, no need for clients to register or download an app (increasing privacy and security at the clients’ side), feature set and responsive customer service.

As we setup the business process, you can signup and try out the app for free. Please post a comment or DM us.

The browser extension gives you a quick access to your buddy list in any tab as long as you are logged into your server instance in an open tab. We are in the process of publishing it different browser stores. Meanwhile, you can download the file and install it manually. It works in Chrome and Firefox.

As we discussed in the previous post, parametrizing the canonical URI provides enhanced features.  In this blog post we will describe the parameters supported in EnThinnai. 

In EnThinnai, we have identified a set of parameters that you specify at the time you generate a customized URI and then share it with your contact:

1. Type:
   1. Text – This is the default. Session starts text exchange. Either party can give permission for voice/video session, then the other party can initiate a voice/video session.
   2. Voice – In this, you had already given permission for a voice session. Your friend can immediately start a voice session.
   3. Video – In this, you had already given permission for a video session. Your friend can immediately start a video session.
   4. Baby monitor – As the name suggests, this type will be used when a parent/guardian initiates a session to a monitor in the nursery. Upon calling, the monitor device will respond and a video session will be setup. Both the ends will transmit and receive video streams.
   5. Pet monitor – As the name suggests, this type will be used when a human initiates a session to a monitor a pet. Upon calling, the monitor device will respond and a video session will be setup. The monitor will transmit video stream, but the human will not.
   6. Door monitor – As the name suggests, this type will be used when an activity at the door initiates a video session to you. The monitor device will transmit video stream, but you will transmit only an audio stream. You will be able to generate an alarm sound that will be audible at the door.
2. Queue: This will be useful in a call center application where you expect more than one person will be calling in at the same time. The caller’s position in the queue and that of the person currently being served will be displayed at both the ends. Unlike traditional phones, there is no need for features like Hold and Music on Hold. This is because, the text session can be kept active with no ongoing media session. When the agent is ready to resume a session, the customer can be alerted with the builtin buzz button. You specify the maximum size of the queue to be 3, 9 or 99.
3. Contextual information: Many times we prefer to receive information regarding an incoming session request. For example, in the telephony world, as consumers we would like to see the Caller ID and the name of the caller. In the business world, the agents are presented with caller’s account information among other things. We have defined four components: Description, Data, Anchor and externalData. The first three are static and is applicable to all the sessions that utilize a particular context. They are defined when a new context is created.The last one is a parameter that is carried in the URI. The idea is that the URI formed when we concatenate Anchor and externalData will contain data pertinent to the session.

A few examples will illustrate the idea better. Supposing you want to get feedback on a document you have drafted. Normally, you will send an email to your contact requesting a review. With EnThinnai, you will place the document in an URL; define the head section of the URL to be the Anchor and the tail to be externalData. You will include thus customized URI in the email. Your contact will click on that URI to initiate a communication session. When you receive that request, you will be presented with the URL where the document is stored, so that you can access it easily. If you have defined the Anchor judiciously, then you can use the same context for other documents as well by changing just the values of externalData.

In a call center application, the business could store caller’s account, browsing history and like in an URL and split it between Anchor and externalData. Then on receiving a session request from a customer, the Agent can easily pull up customer information before responding to the customer.

Anatomy of WebRTC Call URI used in EnThnnai:

Canonical WebRTC Call URI used in EnThinnai is

https://dname.com/pages/iframelogin?from=iframe&owner=<owner’s id>

and parametrized one is

https://dname.com/pages/iframelogin?from=iframe&owner=<owner’s id>[&buddy=<contact’s id>][&context=<encoded context id>][&chatMode=TEXT][&externalData=<string>]

chatMode=TEXT indicates that a chat session should be initiated without an intermediary step. It can be present only if the buddy parameter is included and the identified person has permission to initiate a session.