Talk:Network principles

I think it is very important to emphasize that relying on IPv4 or IPv6 routability means that deployments can improve network conditions independent of changes to the software on the XO. --Michael Stone 15:47, 28 April 2008 (EDT)

Added, thanks. CScott 17:40, 28 April 2008 (EDT)

"fake friends" == "strangers"?

I believe that the term "strangers" better describes what you mean by "fake friends"; the latter incorporates a sense of "deception" where someone pretends to be a friend. Instead you probably refer to users that happen to be physically around and I would assume those to be plain strangers, unless otherwise decided by the user. --Ypod 00:26, 29 April 2008 (EDT)

First comments

Network Principles: "Additional servers may be used as aides or proxies, but the fundamental means to query the state of an XO or to collaborate with its user is to directly connect to it." What does "fundamental" mean? Perhaps you mean "most direct"?

"By direct communication we mean the standard socket API and IP protocols on which the internet is built." You seem to be implying that the standard protocols are preferred, but mesh multicast (especially cerebro's implementation) is a clear example in which the standard protocols are not preferred.

Direct presence interrogation: "The fundamental presence mechanism is direct: one XO connects directly to a service running on the other and queries for its status" Again, I think you want "simplest", as your subsequent algorithm makes clear that this is not the recommended method (piggybacking and lazy presence being preferred, and active interrogation being used only when presence info times out).

"most users have 20 or so friends" I have about 200 buddies on my AIM buddy list. I glanced through my friends on facebook; they often have 600-900 friends (at 98, I am considered an ultraminimalist). Facebook provides constant high-bandwidth presence for all of them, which is only possible due to its centralized, lazy, aggregating architecture. On myspace, the numbers run into the many thousands. We should expect users to behave similarly with our presence service. We should also remember that the presence service bandwidth will only increase, due to strongly desired features like photo buddy icons and live previews of shared activities. The bandwidth will be much lower than Facebook's, but also much larger than the current Presence Service.

"The key point is that all hosts should support direct interrogation for presence, even if other efficient mechanisms are used for partial aggregate presence in some situations." OK, though I think you have your emphasis backwards.

"Our principles above dictate that collaboration mechanisms are built using direct peer-to-peer communication." Umm... except in the case of talking to a user in Google Chat, or any other legacy IM tunneled over Jabber. Now you're using peer-to-peer to mean client-to-server, just like you were complaining about before. Also, "principles" sounds like this is a moral issue; it's not. Finally, what about a wiki?

"Friends are represented internally using the domain name only; there is no "user@" portion." This would make it impossible to be friends with someone on Google Chat. There is no need for this restriction. The domain name can only be "unnecessary" if the user name happens to be "xo", and I hardly see the value of saving 3 characters ("xo@") in an internal representation.

"Additional presence information ... is exported using a simple service at a well-known port." I read "well-known port" as meaning "fixed standardized port". Having a fixed isomorphism between ports and services has been a disaster from the beginning, and every such daemon (http, ssh, bittorrent, ...) has eventually gained a feature to allow it to run on a user-specified port. This is in response to conflicts (two services want the same port) as well as NAT. Please don't do this. It would be much better to let each computer's XMPP daemon serve up a list of services and ports on request. The DNS entry can specify the port on which the XMPP daemon is listening.

Ben 00:30, 29 April 2008 (EDT)

Comments to Scott and Ben

Scott wrote:

"Although the number of possible links in a network grows according to the square of the number of nodes, the interconnectedness of real social networks is quite limited: most users have 20 or so friends, with a few "super nodes" having 100 or so. Directly querying "real friends" should not be expensive in bandwidth or time."

I think there is a distinct difference between "friending" in the context of social networking sites (facebook, myspace) and the network created by the XOs: the former by definition urges users to increasing their social connectivity by adding new "friends", whereas the latter does not provide a "friend" recommendation mechanism and there is no third party (like facebook) that facilitates fast "friending" growth. As a result, friending done using the XOs might be better representation of the actual friend networks among children with relatively fewer edges.

However, I still think that relying on the fact that a child will have few friends so as not to overload the network with presence queries is a sub-optimal approach, not only because may actually end-up having as many "friends" as they would on Facebook, but also because maintaining up-to-date information only about your friends and having no information (what their profile is, what activities they're sharing) about "strangers" will be boring. If you actually have such information about strangers (assuming that no internet connection/xmpp server is available), then why do you need to query your friends on a different basis? Again, I will elaborate more on this on a separate stub.

In response to Ben's comment: "Additional presence information ... is exported using a simple service at a well-known port." I read "well-known port" as meaning "fixed standardized port". Having a fixed isomorphism between ports and services has been a disaster from the beginning, and every such daemon (http, ssh, bittorrent, ...) has eventually gained a feature to allow it to run on a user-specified port. This is in response to conflicts (two services want the same port) as well as NAT. Please don't do this. It would be much better to let each computer's XMPP daemon serve up a list of services and ports on request. The DNS entry can specify the port on which the XMPP daemon is listening.

I think your concern of services corresponding to well-known ports is valid. I would like to generalize the problem though to the case where activities need to be identified and need to communicate from one XO to another: How do activities get identified? By some unique (per activity) id? By some string name? I will write my thoughts on this on a separate stub.

--Ypod 01:24, 29 April 2008 (EDT)