Title
Make LJ Talk able to listen to 21/80/8080/443 ports

Short, concise description of the idea
Make LJ Talk able to listen to additional "standard web" ports.

Full description of the idea
Due to security restrictions 21, 80 and 443 are only allowed outgoing ports in some organizations. So, LJ Talk becomes unusable there because the only port that LJ Talk listens to is 5222.
It would be nice if LJ Talk is able to listen to another "standard web ports" in additional to its native port 5222 (as GTalk, Yahoo, MSN messenger etc are able to do).

• LJ Talk would be usable even behind strict firewalls

• I'm not aware of any performance/security/functionality issues regarding to this suggestion...

Title
about Frank

Short, concise description of the idea
add some commands more to LJ-talk service, for example "add: [Subject] Text" to add some text to already existing topic, "answer: [Subject] Text" to post an answer on comments

Full description of the idea
that's all

• easy to add new sentences to already existing topic through messenger
• not required to use browser, fill login form etc.
• more convenient way to send a post from mobiles

• you need to write a few code more
• you have to test this new code
• couldn't you teach Frank for new options?

Title
add more functionality to the LJ Talk bot

Short, concise description of the idea
Currently, the LJ Talk bot supports essentially 3 commands: post (subject optional), help, and ASL. I would like to add more functionality to "post".

Full description of the idea
I was looking through the code for the LJ Talk bot (sometimes known as Frank) to find a list of its commands (for documentation purposes). While I was there, I found that a few parts of the "post" functionality were commented out and not yet implemented: posting to a community and posting with custom security.

In order for these to be added, they'd need a syntax that could be expressed with regular expressions. I'd like to suggest for posting to a community "Post to community:" as that is similar to other site text. For entry security, maybe a word after Post, e.g. "Post friends to communityname: [Subject] blah blah blah"

• Added usefulness.
• More people using LJ Talk (if only for the bot) to post entries.
• Brings this method of posting in line with some of the most basic clients.
• Fairly easy to code, since some of it is done already.
• Developer attention to this part of the code (which has been barely touched since 2007) may lead to other features being added, such as choosing userpics and adding tags. Maybe even private messaging, if that's easy (although that's another suggestion.) That said, if all that gets added, I'd suggest adapting the email posting syntax instead.
• It would make the upcoming FAQ section on "what are the bot commands" a little more substantial ;)

• Added potential for errors, through mistyping or misunderstanding.
• The internal regexes would become more complicated.
• More complex syntax can be a little harder to document.

Title
Make Frank stop talking (eventually)

Short, concise description of the idea
Stop Frank the LJ Bot from holding endless conversations with IM client autorespond functions.

Full description of the idea
I have certain notifications set to notify me via LJ Talk. My Jabber client is always on, but has auto-away and auto-respond while away settings switched on as well. This means that after fifteen minutes of no action, the client sets my status as Away, and while my status is Away, it automatically responds "I'm not here right now" to anyone who messages me.

Every now and then, I come back to my computer to find Frank and Trillian (the client) holding a very interesting conversation: repeating "I'm not here!" and "I don't know what that means!" to each other at five-second intervals, ad infinitum. It's a bit of a waste of resources, not to mention annoying. I end up having to dig through sometimes HOURS of logs to find the original notification that prompted it all.

I propose that some kind of limit be set to stop Frank from responding with the same thing over and over until the other party stops. Perhaps the limit could be X number of times it repeats its "I don't understand" -line, or X number of minutes, or a combination.

• Frank will no longer waste time and effort talking to another bot ad nauseam.
• Users will not have to sift through hours of this repeated conversation to find heir notifications.

• Frank may start to feel lonely, with no one to hold long conversations with anymore.
• The problem may not be common enough to justify making the effort to fix it.

Title
Add support for Personal Eventing to LJ Talk

Short, concise description of the idea
Add support for XEP-0163: Personal Eventing via Pubsub to the LJ Talk system, for usage such as now playing, etc.

Full description of the idea
XEP-0163 defines a system, based in the older Pubsub system, for Jabber/XMPP clients to send live information on the user, for example, what song is now playing in their media player. Full spec at
http://www.xmpp.org/extensions/xep-0163.html

• LJ Talk users could tell at a glance what their friends are listening to, provided their client supports it
• LJ Bot (Frank) could use this, in conjunction with XEP-0118: User Tune and XEP-0107: User Mood, to set those fields on posts made through him.
• Further out, these things could be posted to the journal, and updated live(ish, maybe no more than once every 5/10 minutes for server load, if that's an issue?)

• Not all Jabber/XMPP clients support sending or displaying some or all information shared through this mechanism (but would still work for messaging!)
• Even for clients that do handle it, not all media players are supported.

Title
Update LJ Bot Frank, so that he knows what pants are

Short, concise description of the idea
Currently, the LJTalk bot, Frank, doesn't know what pants are. Frank should know what pants are, he eats them regularly.

Full description of the idea
Saying 'pants' (or similar) to Frank the LJTalk bot, should result in something sensible like 'mmmmm, chewy' or 'nom nom, THANKS!'.

Currently he just claims not to understand you, and I can only imagine this is very distressing for him. After all, pants have a big impact on his life, and to not know what they are must be very confusing.

• - Frank would act more like his normal self
• - People could give pants to Frank to eat

• - It'll make the code that governs Frank a little bit longer
• - Someone will have to find Franks bot code and alter it slightly

Title
Use Name from profile as display name on LJ Talk

Short, concise description of the idea
Instead of displaying one's user name, use whatever the user enters as the Name on their profile page.

Full description of the idea
Right now, in LJ Talk, one's nickname shows up as their account user name (in my case, diziara). Why aren't we using the name listed in one's profile? (in my case, Just an Object) It seems more intuitive that way, and more in line with the Jabber protocol norm to do it that way, as one's user name is in their login for the protocol (username@livejournal.com) and all the good clients make this information just as visible as the nickname.

• LJ Talk will behave more like other Jabber based communication.
• It will allow users to adjust their name based upon their mood and their current interests.

• Will require recoding whatever currently translates profile information over to the Jabber server.
• May confuse people who aren't used to chat protocols that will allow users to change their display name (but this shouldn't be a big problem, as even the "big names" in chat protocols, like ICQ and MSN have been doing this for years.

Title
Exclude memorial accounts from LJ Talk

Short, concise description of the idea
Accounts which have the "memorial" flag set should be excluded from LJ Talk. The "memorial" flag is only set if the owner of the account has died so having these accounts listed in the LJ Talk rosters serves no purpose and can be upsetting.

Full description of the idea
Accounts can be set with the "memorial" flag when the user dies. As far as I know, this flag has no currently noticeable effect on the account except to disallow new entries, but can be seen by LJ staff.

As described in the suggestion http://community.livejournal.com/suggestions/701246.html the LJ server is responsible for keeping the jabber rosters (LJTalk is a jabber service), which presumably includes who is using LJTalk at all.

• Since any account with the "memorial" flag is owned solely by somebody who has no conceivable use for LJ Talk, and seeing accounts of dead friends in LJTalk can be extremely strange or upsetting, these accounts should be excluded from LJTalk rosters.
  

• Some people leave comments in memorial accounts to say they're thinking of that person, so I'm sure some people also send LJTalk chat messages to the same effect and removing that possibility may be upsetting to some users.
• It could be argued that these accounts should simply be de-friended but because of the unfortunately emotive "Friend" term de-friending the account of a friend who has died is an upsetting idea for all the users that I know.
• Because of the high emotion involved in any decision about an issue like this, LJ will inevitably get flack for any change in any direction.
• Filtering out memorial accounts will increase server processing load, although probably not much.
• Programming and testing the filter will take some amount of time as per usual.

Title
LJ Bot (Frank) upgreade - suggestion

Short, concise description of the idea
new command for LJ Bot (Frank) [lj_bot@livejournal.com]

Full description of the idea
Could you add a command to LJ Bot (Frank) [lj_bot@livejournal.com], to show the allowed HTML - tags.

• this can increase usability of this jabber-bot.

• no problems, I think :)

Title
jabber interface for private messages

Short, concise description of the idea
Create an LJ Talk (jabber) interface for the new private message feature.

Full description of the idea
It should be possible to private message someone from the LJ Talk interface. One way would be some sort of command you can send to Frank. But a better way, I think, would be that IMs sent to an offline user automatically get converted into a message for the message center.

• Easier access to the new feature, especially for people who don't use the message center.

• People will hit rate limits more easily, since the IM interface encourages more use
• The ever-ubiquitous more coding time