Feed on

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 and Lawyers

EnThinnai and Tutoring

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.

Browser extensions

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.

ET-ExtensionChrome_Firefox-Serverless-server-V02-.zip (357 downloads)

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.

To start a WebRTC session, a browser has to visit an HTTP URI. Accordingly, EnThinnai allocates one (which we call your canonical WebRTC Call URI) for you. You can share this with your friends, include it in email signature, or embed it in an iFrame in a web page, like your ID page. But using just the canonical URI is so limiting. We could add parameters to the canonical URI so the application server or your browser could use them to provide additional features or information in real time.

By design, your instance of EnThinnai server is not involved when you originate a WebRTC session. But you can store contact information of a contact in your buddy list, so when you hover the mouse over the contact’s name a link will appear for you to initiate a session with that person.

EnThinnai is effectively your portal for others to get in touch with you or access information that you have shared with them. Architecturally, EnThinnai protects your information is to operate under the philosophy called “Default Deny”. It means you have to explicitly identify who can access a piece of information or can initiate a communication session with you; requests from others will be rejected. It should be added that just because you have given permission for a person to access one piece of information does not mean that they can access all others as well. All these people are collected in a list called Buddy list.

You identify a buddy using one of three ways: the first one is of course their indieauth page (if they happen to have one); the second is with their email id so they can be authenticated using a single use password and thirdly a string that resembles a URL which is not really authenticated but depends on “security via obscurity”. The last method is not really secure; but it is their for your convenience and you need to decide on a case by case basis whether it is ok to use it or not.

An implication of the privacy oriented design is that EnThinnai server is not a position to suggest who are all potential contacts that you can include in the buddy list. You need to bootstrap and populate the list. One strategy could be to graduate a person who contacted you using an unauthenticated id and to one who is identified using an indieauth page or an email id. If you are familiar with strong/weak connections, the first two forms of ids are for strong connections and the third one is for weak connections. 

Older Posts »

Secured By miniOrange
read more today usa gambling games for money online casino real slot machine games online casino payment options online casinos that accept mastercard deposits from us online roulette for USA players first time deposit bonus casino online online slots for mac download casino casinos Classic casino games they offer online casinos that accept usa players bonus code for us casinos online blackjack real money newest casino 2013

united state https://www.euro-online.org online