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.
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)
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)