Message Everyone -- Startup Announcement

Please check out the date at the bottom of the post before sending more inquiries to me and others.

I have taken unpaid leave of absence from my faculty job to work on a startup idea — public codename: “Message Everyone”. Sorry for misleading colleagues and family about my career plans for the last few months.

The idea took shape more than two years ago, when I was organizing the IFL 2015 conference on campus and where I had to communicate with 2 secretaries, 3 more local staff members, and 3 student volunteers; I had to keep in touch with about 8 persons shortly before, during, and shortly after the event to ensure a smooth operation. Upfront, I was offering the following access paths: Skype, Telegram, WhatsApp, Twitter, FB Messenger,  Google Hangout, SMS (and Email and phone). This wouldn’t cover everyone’s messaging preferences and so I would need to install two more apps which I don't remember by now. 

If I ran this conference today, Signal, Viber, SnapShat, LINE, and a few other messaging apps should be on my device. I don’t really mind using different messaging apps. As long as you have a powerful phone and don’t mind recharging during the day, this is easy enough to handle. 

One thing did bother me though (and many times before and after the conference on a smaller scale). That is, you would fail to have effective group communications. Unless you are in a corporate setting, you cannot assume that everyone would be on or join one preferred network such as Slack. Thus, you would constantly spend time on copying over content from one channel to another back and forth. As the person in charge, you would act as a relay service. You would also need to check all the time in all the right places (only slightly simplified by the notification panel) that your infos arrived and are acted upon and replied to. Even worse, knowledge islands would develop because you would forward only when deemed necessary which however subsequently meant you had to contextualize forwards to account for unawareness regarding some previous posts or apparent absence of a person on a given network. What a waste of human brain power!

So our startup (Tel Aviv and London and San Francisco) is going to build the “Message Everyone” app which makes it really easy and secure to connect your existing accounts with traditional messaging services. Our app essentially serves as a messaging mediator (interceptor, forwarder). 

“Message Everyone” does not have any real users — by intention (not to be confused with the Myspace model :-)). We leverage existing accounts with classic messaging services. In particular, the “Message Everyone” app, by itself, will not feature any UI for messaging; its UI serves just the purpose of connecting your ’real’ accounts, creating groups, and some more settings (screenshot in my next post). You will use one of your preferred apps to send and receive messages. In a group communication, not everyone has to install our app. In practice, it is enough, if just one person has the app installed. However, everyone has to confirm, based on a messaging-based micro DSL, to participate in an inter-messaging service group. Privacy is the biggest challenge, but we think we have a simple solution. :-)

To better understand how it works, consider a group communication where users U1 and U2 want to talk to each other. U1 uses service S1 whereas U2 uses service S2. 

Communication succeeds if:

• Base case: S1 = S2 and U1 and U2 are connected on S1=S2. In this case, of course, our app is of no use, but the base case is as useful as in the case primitive recursion.
• U1 has our app installed (U2 hasn’t necessarily) and U1 and U2 are connected on S2. This is the case where U1 can use S1 effectively and relaying to S2 works locally on the phone of U1 by virtue of our app. In an extreme case, U1 has all conceivable services installed and can message all users from all services for as long as U1 is connected to a user on at least one service. (I would be U1 in the conference scenario.)
• There is another user U3 in the group on a service S3 such that N1 and N3 as well as N2 and N3 can communicate. This is some sort of transitivity aspect of "Message Everyone". N1 would not be able to add N2 to a group communication; N1 would rely on N3 to kindly do that. Thus, groups have no manifestation beyond the fragments of connected users on any given phone.

Thus, everyone can safely message everyone else in the most heterogenous group and that’s our mission! All such messaging would be consensual and existing apps could easily add an option to suppress relayed messages, if users are concerned. (In my conference scenario, this would correspond though to some sort of riot.) 

One question that I am getting a lot is this: What’s the business model of MCS? More technical people start off with a different question: What does it take in terms of infrastructure and staff? The answer is ‘very little’. In one approach, “Message Everyone” would rely on the existing services to maintain active sessions and groups. We feel this may be too much to ask for. Also, it could trigger privacy concerns. Instead, we favor a peer-to-peer model at this point where sessions are maintained by group participants with our app being installed. Zero info about group participants is cross-posted or made available in any way to other group participants on different services or without friend relationship on the same service.

For classic services to participate we only rely on APIs for intercepting and sending messages and accessing contact lists for the apps. Everything happens on the phones. We do no rely on any server infrastructure. The existing APIs for most messaging apps do pretty much already today provide sufficient means, but we are getting in touch with all the players to tune things. We need few app developers. Most of our effort will go into setting up collaboration with existing services to ensure their smooth integration. For instance, I am visiting Facebook after Easter.

Stay tuned. 

Ralf

1st April 2018