July 22nd, 2001

  • xb95

LJU Client, Chat Server?


This is my first post to this group, and there are really three reasons for this post. First off, I notice that in user profiles, you can check what clients they use. I.e. in my profile you can see I use a whole host of Win32-*LJU clients. They're really one client, one I've been developing and is coming along quite nicely. The question is: how do you get statistics on who uses the client? This is mentioned in the Developers area of the LJ site and I'm wondering--how can I see how many people are using a particular client?

LJU (LiveJournal Updater, for lack of a better name) has not been released to the public yet, so there should only be two, maybe three people using it. But when it is released, hopefully in the near future, I'm going to be curious. :)

The second point I'd like to bring up is a chat server. I was writing in my journal today and the idea came to me: what if we allowed people to initiate client to client chats, file transfers, you name it. The whole idea of LiveJournal is about community, right? What better way to help foster people meeting people than by giving them an easy method to get to know eachother?

I propose a very simple, decentralized system which requires only a slight modification to the LJ server. Add a new key-value pair called chatip which allows the client to pass in its IP address to enable chatting. Then, let's say I'm interested in chatting with bob, I can send a getchatip event with user=bob, and if the server has a chatip on file, it returns it, else it errors. The client can then contact that IP address to see if they're around and update the buddy list, etc.

The second method, requiring no server modification, is to setup a secondary server dedicated to chat. Users would login to the chat server much like they login to LJ, and the chat server would fake a login to LJ to see if the username and password is valid. Then the IP addresses could be passed out by this secondary chat server. Hm, on second thought, that might be the better method anyway. Let LJ focus on what it's good at, and let the chat system be an optional plugin set of Perl scripts which the user can add about.

Third point: who do I talk to about getting my client linked to on the LiveJournal download page? :) Also looking for beta testers, if anybody is interested. Drop me a line, xb95@yahoo.com.

Okay, enough disjointed ramblings. My apologies if this has been brought up before. Feel free to lay out the smackdown if necessary! Also apologies if this messes up--this will be the first time the client has posted to a journal other than my personal journal.
  • Current Music
    Enya - Lazy Days
moose, transparent
  • avva

More thoughts about a large number of friends

Many people were wondering in this thread why someone would have more than 100 (200? 500? 1000?) friends.

Well, here's a very good example why. The Russian-writing community (in the informal sense of the word) on LJ numbers about 900 people currently. There's a user who adds to his friends list all Russian-writing LJ users who can be discovered (in other people's comments, in other Russian-writing people friends' lists, etc.). This is done specifically in order to allow people to read all Russian LJ journals in that user's friends view. This fact is widely known among Russian-writing LJ users, and many dozens of people (a counter's been used to measure) read that user's friends list daily in order to find new interesting journals in Russian, and to keep up with many interesting people. I do that daily, for example; the relevant link is right there on my browser's toolbar. In reality, of course, not everyone of 900 people on the list updates daily, and though some others update several times a day, I (and other users using this) manage.

You wondered what could possibly unite 1000 different people together in one list? So here's one possible answer for you: language. For all I know, people writing in other languages may be employing the same method currently on LJ. I wouldn't be surprised.

Of course, at some point doing that will become impractical - maybe when the number reaches 2000, or 5000, who knows (the community grows fast: just a month ago there were 600 people in the list, two months ago - 300). But it's certainly not impractical yet; in fact, it's hugely beneficial to very many people.

I strongly feel that the number of friends should not be limited at all, with a possible (and still undesirable) exception of a really ludicrous number. 100, 200, 500, 1000 are not such numbers; 100,000 may be.

The discussion on how such a large number of friends harms LJ's server resources has centered on the userinfo page issue, and I feel that this is not that big an issue. The real issue, for which I haven't found any answer is: does using the friends view impact the server in any severe way? My gut feeling would be that it doesn't, not with 1,000 or 10,000 users - considering e.g. that the stats page is happily showing the latest 10 updated journals among all the 250,000. However, someone probably knows better about this -- please speak up!

As for the userinfo page, the performance impact here surely can be
reduced without putting any hard limit on the number of friends. For instance, why not add an argument with a max number of friends to fetch to the 'getfriends' protocol mode (for compatibility, make it an getfriends_ext mode)? userinfo.bml could then use that argument in order to fetch no more than say 500 friends to show on the page. Or, the number of friends can be maintained in the database (rather than dynamically computed) by the code that adds/removes friends, and that number can be checked when fetching a friends list from userinfo.bml; in case it's too large, only display the number of friends and not their names. Or... there're many other possibilities. If that's the real problem, let's discuss it and solve it, rather than crippling users with an arbitrary hard limit.

Thanks for listening! I'll be getting off my soapbox now.