Talk:Instant messaging challenges

March 27-06: SoreThumb: "I may admit to be a bit ignorant of the situation even after reading the article, but sometimes outside and somewhat-ignorant thoughts offer new insights: Why not have the mesh network part integrated into an IM system specifically for the OLPCs?
"So to speak, each computer would have a unique serial #, and each computer would store the custom username.. If you can turn it on and log in, you technically would have the rights to using the IM name linked to the Serial.
"Also, it may be CPU or network-heavy, but when each computer signs onto the network, it obviously has to poll the local area for available OLPCs, right? Why not have this as signing-onto the IM system: all OLPCs recieving the network connection would send out notification of presence like a ripple from a pond.
"In any case, this network could technically not be that secure. If I'm not mistaken, you'd be sending your IM across other computers until it reaches its destination, with possible party-interest. Perhaps a global chatroom?
"I hope I adequately discussed the possibilities of a possible system." - NBST 2006

I think Sonork [1] would be excelent for the system. It has not only offline messaging, but offline File Transfer!

I think that what is needed is something that will work well over a peer to peer system. Probably what you want to have happen is that a person wants to orignally use a system they would have to connect up a centralized server. When they connect and get a userid, it would then send data back to the client of a signed digital certificate. Aka, when I sign up I would get a signed digital certificate saying that I am profdeadmeat signed by the server that we all know. Probably this should use the Jabber protocol. When we are using a regular non supported network of peer2peers then what would happen is that machines would query machines around them for instant messanging.
   It looks like the Zero Conf Group and the mDNS/DNS-SD groups may have figured parts of this out. A product that does some of what you are talking about is Bonjour ichat which is Apple's name for ZeroConf does do peer2peer chatting.

 Note: some of the above has moved to the main page if you need to speak to me contact me online
  via AOL or email me via gmail to my account.

Linking a user account to a physical machine is very restrictive and is the wrong representation of reality. What you would be saying is that the identity of the machine and the identity of the user are one, which could be temporarily passable, but is a bad long term strategy. Think what will happen when the LCD breaks and the kid gets a new laptop.

It is reasonable though to use a machine's address and assume that it is "temporarily" associated with a user's id. IPv6 makes this much easier because of the partial mapping between of mac addresses to IPv6 IPs. This would be similar to the way in which a user's public key is cached to allow for p2p authentication. This will simplify the discovery process and could (more importantly) reduce network traffic.

Another point to make is that the scale and reach of discovery needed for mesh networking is very different than that for an IM network overlap only partially. Which means that the minimum discovery area needed to cover both will be larger than both, which leads to the undesired effect of more network traffic. In simpler words, when you start a mesh network you only need to find your immediate neighbors, when you start an IM network, you need to find a specific set of users in your body list, regardless of whether they are your neighbors or 3000kms/10 hops aways.

5/16/2006 - khassounah - thoughts on proposed approaches:XMPP is most likely the best option out there. It is widely supported, mature, and is the most extensible option. The challenge though is that the current proposed approach for serverless XMPP has limitations that make it not suitable for HDLT's purposes (yet) and introduces some serious security issues.

It doesn't provide anyway for users to authenticate each other for instance. This means that the proposed protocol is introducing a huge security flaw that email suffered from for ages (think smtp). Suddenly, any user with a client can impersonate any other user and send message to people connected to them. This is not a huge issue in a physical link-local network (it still is, but not as critical), but is more of an issue in a logical link-local mesh network where any wifi-enabled computer across the neighborhood can impersonate any other user, and where a child can receive a message that appears as if it's coming from their friend when it is actually coming from a pervert.

The severity of this issue becomes greater when we realize that these children will have addressable ipv6 addresses. Unless you want an application to worry about layer 3 addressing and differentiate between local addresses and global ones. Which means access to those children is not limited to neighbors.

The other issue is that it assumes that access to the server and the peer to peer mode of operation are mutually exlusive (at least by design not statement). Which is valid when thining about link-local networks, especially that link-local addresses (by specification) are not to be used in parallel with normal network addresses (except in a limited way while in transition). The implications of that are that smooth transition between the two modes when you gain and loose connectivity to the server is harder to achieve, and that you can't use peer to peer connectivity while you have access to the server (which might be a considerably more efficient in some cases)

These are not necessarily flaws with the proposed standard, since the standard seems to have been created to provide a simple presence-enabled paging system that makes use of link-local connectivity. What is needed though is more of a peer to peer alternative to server connectivity, and which could still function as flawlessly and as "securly" as a server-based connection.

5/24/2006 - philbo - why not email?: I can't see how usually-disconnected IM is any better than email, and might actually result in a worse user experience because most of the assumptions behind IM are violated in a disconnected scenario. How is severless XMPP any better than an email client with a buddy list style address book and nice threaded message display.

6/2/2006 - khassounah - email v.s. server-less IM:Disconnected here meant disconnected from the server not from each other. A better name would have been peer-to-peer. We are talking about a situation where the kids are in reach of each other, but only of each other. They should still be able to instantly communicate

Messaging Servers On Each Laptop

Totally distributed. Completely independent from the Internet.

• centralistic? no no no. distributed. you can even call it federated. yes please!
• if every laptop has a unique and reliable IPv6 address and DNS name, it can run its own messaging server (be it ejabberd or psyced or whatever) and host all of its local users.. mums dads sisters brothers grannies grandpas uncles and aunts.
• given this architecture, all client apps can reliably talk to their home server no matter what the network situation is, because it is running as a daemon on the same machine.
• only the server needs to figure out when it is in reach of other servers, or when it isn't. this may be the whole big internet, but it may just as well be just the next ten laptops within radio reach.

to this purpose we need a special hook that will pass the information of available stations from the radio drivers of the kernel to the messaging daemon, so it can get in touch with them.

• yes philbo, why not also email. email has a decades long tradition of dealing with temporary link-ups and offline messaging. think UUCP POP3 etc. considering that a network of laptops will want to exchange email even if the internet is unavailable for a week, good ole UUCP technology is the way to go when it comes to email. but then again... SPAM!

--lynX 10:00, 25 May 2006 (EDT)

6/2/2006 - khassounah - messaging servers: I don't see why not, but this is really an implementation detail. Whether you call it a server or a client accepting connections, at the end it is whether one machine can connect directly to the other or not. If you are talking about registration and user management though, then that's a hairy question, and needs to be thought out carefully. The reason is that you want a system to work both locally and globally, and there likely will need to be more than one solution combined.

Just to give you a taste of the design challenge: if I have a server on my machine, then why do I ever need to login to the server on your machine? is it that not all machiens have servers? in that case how will anyone know where I'm logged in at anytime, especially that it will have to be dynamic since your machine might not be always on or in sight (from a networking perspective), so I should be able to login to another machien available. the challenge then is where does user x find me? if they want to subscribe to my presence and be notified when I come online, which server do they login to?

You are trying to solve two problems at once: discoverability and robustness. Any solution needs to solve both problems. Skype is very robust, but has serious discoverability issues. Most others (MSN, AIM, Yahoo, Jabber) are discoverable, but extremely rigid (no internet, no IM).

SPAM, E-Mail, Messaging

With young people in the world e-mail is slowly going out of fashion - it is considered too formal and at the same time too SPAM-prone. They turn to massive instant messaging and web-based communication platforms like myspace and friendster. Both these technologies are typically proprietary. We can't and shouldn't keep anyone from joining in on this, but we can take our new users by the hand and offer them a friendly non-proprietary SPAM-unlikely technology to head out with, first. The obvious candidate would be Jabber/XMPP, this raises questions though:

• Is the protocol too verbose for Real World Internet bandwidths?
• Can it be extended to serve as a spam-free E-Mail replacement?
• Does it have enough profiling and social networking fun aspects?
• Is it architected well enough to handle the load?

Myself I am working on a protocol which does address these issues, and is gateway-compatible to Jabber and E-Mail, but I wouldn't dare to say we're ready to step into these shoes. From an insider's point of view I know that using XMPP to these purposes will be tricky at best.

--lynX 08:57, 25 May 2006 (EDT)

Where is the creative thinking???

Quite frankly, this whole IM discussion is silly. You are all thinking like Americans who sit behind desktop computers in the office all day. Have you ever thought that this problem might have already been solved somewhere else where people do not live in the same technology environment as you do?

I already have an OLPC IM prototype that has been functioning for the past 7 years for me. It has existed longer than that, but I've only used it for 7 years. When I write an IM, it goes into my "To be sent" box. I select the destination from my "Buddy List" or I type in the raw destination address. On my OLPC IM device I also have a Python interpreter and I use a Python app to search a Russian-English dictionary that I have installed on my 512 megabytes of memory.

The device is called a Nokia N-70 and it is a typical European GSM mobile phone. The IM service is called SMS and it functions without any persistent connection to a server. The "Buddy List" is called the "Phone Book".

The CPU power and storage capacity of my Nokia N-70 are quite similar to that of the OLPC. My mobile phone is not always "Online". Sometimes I am in an undergorund train or I might even turn it off. But when I connect again, the SMS messages pour into my Inbox and I can deal with them.

The Motoman service in Cambodia is probably even a better model. http://dailywireless.org/modules.php?name=News&file=article&sid=2003

Note that this blurs the lines between e-mail and IM. Since the OLPC is going into an environment where western-style Internet connectivity will not be available for a long time, I think that we need to accept the fact that IM on the OLPC will be more like Pony Express email than like traditional American AOL/Yahoo/Google/Microsoft IM.

lynX, who forgot his password and isn't getting e-mail from the wiki, would like to comment:

Alternate technologies need the adequate infrastructure. I doubt GSM is available in all involved countries at affordable prices. You just ignored the point that SMS cost money, and in our constellation even GPRS or UMTS are too expensive to allow for laptop.org chat and file exchange, unless you can convince providers in those countries to give away GPRS for free to everybody (How could you limit it to OLPC laptops?). That might work in Estonia, but not where these laptops are going. Also I dare to suppose that the biggest part of the social network of these children is in close geography, so chat and file exchange based on wireless LAN technologies that need no outside support sound like a quite good idea. And yes, I am European too.

lynx, I'm not saying that we should use SMS mobiles instead of IM on the OLPCs. I'm trying to point out that there is a widespread working model of IM that does not use longlasting connections to servers and it works. IM on the OLPC does not need all the clutter of the American centralized IM model. In fact, IM on the OLPC needs to move even further than the European SMS model and function with no servers at all.

For example, a kid should be able to send an IM direct to another kids device. The "buddy list" should automatically populate with any devices within wi-fi connectivity. But, at the same time, the kid should be able to address non-connected machines to be delivered later or to be relayed via relay-points. I think I will write some Use Cases on the main page.