Talk:Instant messaging challenges

From OLPC
Revision as of 18:13, 16 May 2006 by 18.85.46.108 (talk)
Jump to navigation Jump to search

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.

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.