Suggestions Box

Show "preapprove poster" checkbox to community maintainers only

2008-10-01T15:07:05Z

Title
Show "preapprove poster" checkbox to community maintainers only

Short, concise description of the idea
Don't show "preapprove poster" to community moderators on the entry moderation page unless they're also maintainers.

Full description of the idea
Currently, that option is present for all community moderators, whether they're also maintainers or not, but can be used by maintainers only. The "successfully approved" message ignores that and claims the poster was added to the "can post unmoderated" list for the community. This suggestion would remove that option (and the attempt to add the poster to the list) when the moderator isn't also a maintainer.

An ordered list of benefits

Less confusion from options that silently fail to do what they claim.
Less worry by half-awake moderators that their mistakes may have harmful consequences

An ordered list of problems/issues involved

Disappointment from moderators who enjoyed having that option offered, even if it doesn't actually do anything.

Allow users to set site scheme for their profile page

2008-10-01T15:06:57Z

Title
Allow users to set site scheme for their profile page

Short, concise description of the idea
Allow users choice of site scheme to denote what site scheme is shown on THEIR OWN user info./profile page.

Full description of the idea
On the Viewing Options page, users can set which of the site schemes (with the exception of Lanzelot for those of us over this side of the world) they want to see around the site.

On the Viewing Options page, directly below the scheme selector, there should be a ticky box saying something along the lines of "enable my site scheme preference on my user info./profile page".

An ordered list of benefits

People can get the look they want on their profiles.
We - the users - get to see who likes which site scheme.
Profiles created taking into account the width of a page in one scheme will now no longer have to be ruined by being viewed in another scheme (example; I think my profile page looks naff in Horizon and XColibur, while some people like to use the width that those schemes provide).
It'll make profile pages more individual, and in keeping with creating our own journal style, without being overly imposing on others.
People will be happy. :)

An ordered list of problems/issues involved

People will complain/panic when finding a page that doesn't look like they think it should.
Someone's gotta do the coding, and I don't know how much back-end coding such a thing would take.
No doubt someone'll come up with other stuff I've missed. ;)

Screened Comment Display

2008-10-01T15:06:51Z

Title
Screened Comment Display

Short, concise description of the idea
Display screened comments the same way on customized entry pages as they are on site scheme pages.

Full description of the idea
Currently, on site scheme entry pages, when a comment from a user is screened, the page displays (Screened Post) to those who cannot see the comment. However, on customized entry pages (those that match Paid and Plus user's journal theme), a screened comment is displayed like this:
(no subject) - [ljuser img] Expand

(The Expand link only shows to Paid users, if I'm correct)
Clicking on the Expand or "no subject" link essentially does nothing. It makes no sense to me why there are two different display methods, other than the possibility that screened comment display just wasn't built into the S2 Core layer.

An ordered list of benefits

It's confusing to people who don't realize the comment is screened and try to click on the links.
Similarity in the user interface between site scheme and customized pages.

An ordered list of problems/issues involved

Developer time taken, obviously. I don't know if this change needs to be made in all layouts, or just in one place on the backend.

Override the custom comment pages of other users

2008-10-01T15:06:41Z

Title
Override the custom comment pages of other users

Short, concise description of the idea
Entry and comment pages not belonging to the user would be displayed in Horizon, Vertigo, or Lynx styles.

Full description of the idea
I personally write short entries that are very easy to read (in my opinion) in a small, light font. If I want to read a large article in a journal someone has custom comment pages for, I have to either view it in my style or theirs. Custom comment pages are tailored specifically for the journal they are applied to and may not always be very beneficial to other users. I used the whole '?style=mine' thing constantly before I became a paid user. I shouldn't have to sacrifice the way I want my journal to look because of the way other users decide to style their own journals (and vice versa!).

An ordered list of benefits

More user-friendly browsing.

An ordered list of problems/issues involved

I personally can't think of any.

force style=mine on all individual entries, but not on all journals

2008-10-01T15:05:41Z

Title
force style=mine on all individual entries, but not on all journals

Short, concise description of the idea
I'd like the option to force all comment pages into my style, but without it affecting other pages.

Full description of the idea
Right now we have two options in this vein, but I'd like a third middle-of-the-road option.

Currently we can either have it so that 1) following a page off our friends list automatically appends style=mine, or 2) every page on LJ is displayed in style=mine.

I'd like a compromise between these two options: the ability to force all comment pages into my style without it affecting the main pages of journals and communities.

I always view individual entries in my own style, but I like to view journals and communities in their style because they may have extra content/navigational sidebars that don't show up in my layout.

An ordered list of benefits

Allows users to view all individual entries in their own style while communities and journals retain their formatting.
Stops users from having to manually append style=mine to comment pages they did not travel to from their friends list.
Adds a finer level of control over how users view LiveJournal.

An ordered list of problems/issues involved

Just some extra coding.

Comment Thread Collapse

2008-10-01T15:05:35Z

Title
Comment Thread Collapse

Short, concise description of the idea
I would like the ability to collapse comment threads that have been expanded, possibly even hide individual comments.

Full description of the idea
I really love the fact that we can now expand comment threads without leaving the main post. Unfortunately, some of the threads are so deep, I find myself wanting to re-collapse a thread after I finished reading it. At the moment, the only way to do that is to reload the page and let all of the expanded threads collapse.

Additionally, the idea of collapsing threads or hiding individual comments would allow one to hide comments and comment threads one doesn't wish to see, but has no ability to remove or screen.

Perhaps this can be done with a +/- symbol to expand and collapse a given comment or comment thread.

An ordered list of benefits

Greater flexibility in reading comments.
Ability to hide undesirable comments and only see the comments you wish to see.

An ordered list of problems/issues involved

I can't think of any drawbacks to this. You are only changing what you see, not what any other user sees.

Review the Mood Set

2008-10-01T15:05:28Z

Title
Review the Mood Set

Short, concise description of the idea
LiveJournal should use the thousands of entries already on its servers to double-check that the mood set is meeting users' needs.

Full description of the idea
This idea comes from a comment in a recent suggestion for additional moods: http://community.livejournal.com/suggestions/875143.html?thread=13478791#t13478791

Essentially, LiveJournal can/should datamine all entries (regardless of privacy status) to provide an aggregate report of which moods are being used most often. Both the default moods (hungry, good, mad, etc) and the 'alternate words' that people enter free-form should be compiled.

This will provide actual data for whether or not some entries are completely unused (extremely unlikely) or whether some free-form entries are so common that they should be added to the default mood set.

An ordered list of benefits

Actual data informs the decision, rather than individual Suggestions that provide a biased sample.
Happy/Hungry/Exanimate users have nothing to fear.
Musical/Meh/Snarky users have everything to gain.

An ordered list of problems/issues involved

Serverload for the queries will obviously be a concern, but should be able to be alleviated/minimized.
Variant spellings/plurals, and punctuation in free-form entries may skew the results somewhat. Anything high enough in the rankings to be considered for inclusion should be able to be seen by visual inspection of the aggregate data, however.

Purchase History Link

2008-10-01T15:05:21Z

Title
Purchase History Link

Short, concise description of the idea
Add a Purchase History link under your Store menu.

Full description of the idea
n/a

An ordered list of benefits

I could only find it when making an actual purchase. It was very inconvenient.

An ordered list of problems/issues involved

Alphabetising option for userpics

2008-09-23T14:02:29Z

Title
Alphabetising option for userpics

Short, concise description of the idea
Currently, there is no option to alphabetise userpics on either the allpics page or the manage userpics page.

Full description of the idea
The only option for ordering userpics right now is upload order. I'd love for there to be an option to order them alphabetically by keyword.

I believe this tends to become more of an issue when a user has more than just the six default icons - there are many userpics to scroll through and no real order to them.

This has been discussed previously (http://community.livejournal.com/suggestions/502655.html) but as far as I can see, nothing came of the suggestion. However, that was a long time ago.

I recognise that this suggestion brought up some issues in 2004, which I'll address under 'problems and issues'.

An ordered list of benefits

1. Better organisation: neater pages. It would be so much easier to find userpics pertaining to the same or similar subjects or made by the same artist.
2. It will be easier to see what userpics have been uploaded for a specific subject if the keywords are orderly.

An ordered list of problems/issues involved

1. As brought up in the previous suggestion, this could pose problems for those who have more than one keyword per userpic. Which keyword would the picture be alphabetised by?
2. It could be time consuming to implement this feature.

Friend Suggestions

2008-09-23T14:02:22Z

Title
Friend Suggestions

Short, concise description of the idea
Friend suggestion feature on profile.

Full description of the idea
A button on the user's profile that would allow another user to click it and select anyone from their own list to suggest to those users (the profile user and the chosen user) that they become friends.

An ordered list of benefits

Easy, convenient friend suggestions
Less awkward friend suggestions
Easier time meeting people/networking

An ordered list of problems/issues involved

None

Fewer steps for tracking comments

2008-09-23T14:02:12Z

Title
Fewer steps for tracking comments

Short, concise description of the idea
When posting a comment, I would like to see a check-box for "track this" right there on the "post a reply" screen, for fewer steps required to track comments.

Full description of the idea
Many users like to know when the original poster has responded to their comment -- sometimes, but not always. So right now, after posting the comment, you can click "track this", then another screen, and then a button where you say yet again, yes, I definitely want to track this. But how much easier it would be if right on the screen where the user is posting the comment, there's a check-box for "track this"? Fewer steps. Much easier. The check box would be unchecked by default, therefore there would be no problem with unwanted tracking.

An ordered list of benefits

Fewer steps for the LJ user.
Would, I believe, increase the number of tracked threads, thereby increasing the amount of inter-user communication onsite, which can only be a boon to LJ.

An ordered list of problems/issues involved

Obviously, any technical reason unapparent to the layperson but that would pose a problem from the developers' end.

ability to delete several subscriptions at once

2008-09-23T14:02:04Z

Title
ability to delete several subscriptions at once

Short, concise description of the idea
On the Manage Subscriptions page, you can only delete (using the trash can) one subscription at a time, and I'd like to have that changed.

Full description of the idea
On occasion I will subscribe to several comment threads on a temporary basis. That means later I have to go back and delete those subscriptions to free up space. Right now, you can only delete one subscription at a time-- clicking the trash can immediately refreshes the page. (You don't even get a "do you want to do this?" message!) This gets annoying. You can unsubscribe in a group by checking the checkboxes and hitting save. Why shouldn't we be able to delete the same way?

An ordered list of benefits

easier to manage subscriptions
less refreshing
looks nicer
less chance of accidental deletion

An ordered list of problems/issues involved

coding time

Display pending schools by country

2008-09-23T14:01:56Z

Title
Display pending schools by country

Short, concise description of the idea
Display a list of schools that are waiting to be approved by the Schools team to the general userbase.

Full description of the idea
Currently, when a user submits a school to the Directory, it must be approved by a member of the Schools team before it is displayed on the user's profile and in the Schools Directory for other users to add. If another user wishes to add the same school, or if the same user doesn't understand the process fully, duplicate schools are added, or the same school with a different spelling or format is submitted, which causes the pending queue to fill up and duplicate schools can accidentally be approved.

The idea is for a list of pending schools to be displayed by country, then by state, city, and school name - Separate pages for each country would be ideal, then all the pending schools would be listed on that page in the sort order above.

An ordered list of benefits

Less duplicate schools will be submitted, keeping the pending queue to a more representative number and enabling the team to approve much more quickly.
An unintended side effect will be that users will be able to see if/when their school has been rejected - it will disappear from this page and will not appear on their profile if it is not approved.

An ordered list of problems/issues involved

An increase in Support requests is possible when users can see if their school has been rejected.
When the queue is really large, it could be difficult to check to see if your school is pending or not.
Will likely not prevent the problem of the same school being submitted in different cities.

Set Community Moderation Queue to Local Time Zone

2008-09-23T14:01:49Z

Title
Set Community Moderation Queue to Local Time Zone

Short, concise description of the idea
In addition to journal entries and comment displays, extend the "Time zone" option to display the community moderation queue to the local time zone specified.

Full description of the idea
In the "Edit Profile" section in LiveJournal [http://www.livejournal.com/manage/profile/], there is a section to set the time zone. Once specified, this changes the display of journal entry times (i.e. the time displayed when composing a journal entry) and comment times (i.e. the time displayed when posting and looking at comments).

This time zone setting, however, does not appear to extend to the community moderation queue. The moderation queue is displayed in military time and is seven hours ahead (from my setting, at least).

Here is an example: My time zone setting is "US/Pacific". It is 2:17 pm on September 10, 2008. In a community I moderate, an item just popped up in the queue with a time of "2008-09-10 21:17:40", or 9:17 pm. The two times are out of sync.

Based on the above, I propose that the settings for the queue to be changed to accurately reflect the time zone specified in the profile setting.

An ordered list of benefits

Accurately display moderation activity.
Better knowledge for moderators of how long an item has been sitting in the queue.
Accurate and customized time based on LiveJournal member's time zone settings.

An ordered list of problems/issues involved

Initial time to research and update coding.

Remove the "Writer's Block Module" from Welcome to your LJ page

2008-09-23T14:01:43Z

Title
Remove the "Writer's Block Module" from Welcome to your LJ page

Short, concise description of the idea
I believe that modules in the LJ welcome page should not be mandatory, but that a LJ owner should be able to opt out of them.

Full description of the idea
I am very annoyed at the fact that every time I sign in I'm confronted with a module called "Writer's Block". Now for those interested
in such things, this would be fine. But my LJ is
a visual one, I'm an artist as opposed to a writer, and the presence of the damn this is annoying. Can we please make it so that modules can at LEAST be keyed to interests. I might be interested in an "Artist tips"
module for example. Users should at least be able to opt out of having to see a module (have it so the text is hidden until you click on a button or something like that.

Call me a curmudgeon, but I'm sick to death of seeing that module every time I sign in!

An ordered list of benefits

Customized content makes for happier LJ users.
Less clutter to welcome page of journals.

An ordered list of problems/issues involved

None known.

Previous/Next option for Virtual Gifts

2008-09-23T05:23:51Z

Title
Previous/Next option for Virtual Gifts

Short, concise description of the idea
When viewing virtual gifts (yours or those of another party) have the previous and next virtual gift linked.

Full description of the idea
If your friends have each given you literally a million birthday wishes, in the form of virtual gifts, you currently must either click on each link in each virtual gift notification, click on each virtual gift from your profile page, or manually enter the location of a current active (or expired) virtual gift that you have been given. This is a pain.

You should be able to navigate forward and backward from any given virtual gift, to view the whole range of love, affection, appreciation and occasionally way too much free soda that your friends, admirers, co-workers, and tomato-throwers have shared with you.

An ordered list of benefits

Ease of use
Doesn't provide viewers with something that they couldn't already do manually
Literally a million times better than hitting the back button and clicking the next one

An ordered list of problems/issues involved

People who may not have been aware that virtual gifts that have expired from the profile are still viewable if you type in the URL would be able to see older gifts
Skipping may prove problematic for deleted virtual gifts
Developer time / user benefit tradeoff
Blinkie the Ponie and the real Blinkie the Ponie may realize they are close enough to fight, and start an epic battle, but Super Frank may not be close enough to break it up.

icons for virtual gifts

2008-09-22T17:53:53Z

Title
icons for virtual gifts

Short, concise description of the idea
You are missing some possible gift icons.

Full description of the idea
I need a magic wand. A unicorn. Possibly a fairy. Maybe you should have a specific suggestion box just for virtual gift ideas?

An ordered list of benefits

You'd make some money.

An ordered list of problems/issues involved

Someone has to make the dang icons.

Wistful mood

2008-09-22T17:53:46Z

Title
Wistful mood

Short, concise description of the idea
I and several of my friends would really like a "wistful" and an "affectionate" mood added - no currently existing moods really suit.

Full description of the idea
The summary pretty much covers it.

An ordered list of benefits

Just more richness in posting.

An ordered list of problems/issues involved

The need for icon makers to create a new icon.

Multi-plataform LiveJournal client.

2008-09-22T17:53:37Z

Title
Multi-plataform LiveJournal client.

Short, concise description of the idea
Create an official, multi-plataform client, that is regularly updated (or as often as it needs to be anyway).

Full description of the idea
Realistically, the only LJ client that is frequently updated is Semagic. And it is primarily Windows-based (yes, I know it can be used on Macs as well, but not without another third-party application, and some rather complicated fiddling to boot). Clients for Mac are suffering from a severe development draught; I can scarcely imagine what it is like for Linux users. So I was wondering earlier today if LJ themselves couldn't develop a multi-plataform client for us to use, regardless of which OS we operate with. I've just realised this myself, what with my purchase of a Mac, when I didn't really like any of the available clients, and I thought there would be a very slim chance any of those would be updated soon. Maybe having it as an open source, we can have various people pinching in with new ideas and whatnot.

An ordered list of benefits

Being a multi-plataform software, pretty much everyone use it.
Frequent updates to the client. Rarer chances of it being obsolete.

An ordered list of problems/issues involved

None! Or so I'd like to think...

Option to View Entries Without Displaying Comments

2008-09-22T17:53:30Z

Title
Option to View Entries Without Displaying Comments

Short, concise description of the idea
I would like to have the option to display an entry in its entirety (including the portion underneath an lj-cut) but without displaying the comments.

Full description of the idea
(I searched for a similar suggestion but couldn't find one, so if one does exist, my apologies for submitting this one.)

Someone actually wanting to view an entry without displaying comments? You may be wondering why anyone would want to do such a thing.

Well, for some posts that have lj-cuts (especially those in <^>news and other journals or communities that frequently get many comments), I may want to just read the full entry itself but not the thousands of comments underneath it. This may be because I'm pressed for time, and a page with many comments takes much longer to load. Or I may be viewing the entry on a mobile device, in which case an excessive number of comments may cripple my phone's functionality. Or I may want to print the entry itself but not the comments. There are probably other reasons that an option to not display comments could be useful, but those are the ones that come to mind immediately.

Please note that this would strictly be an entry-specific display _option_ that the viewer can toggle on their end. Perhaps this could be implemented as a URL argument like "?displaycomments=no" or somesuch. On the entry page, there could be a link to the URL with the argument, with the link text "Display without comments," etc. There are probably other ways to do this, but that seems to be the most obvious to me.

An ordered list of benefits

More flexibility in entry viewing.
Less time to load entries that contain numerous comments due to less overall content when this option is used.
Easier to load entries on mobile devices or older computers when this option is used.
The ability to print the full entry without the comments if the user so desires.

An ordered list of problems/issues involved

As with every other suggestion, the time and trouble to code it, especially if this would require a new entry argument.
Some people might not like this idea, although since it would be purely optional, I'm not sure exactly why not. (Though I'm certain that you guys will fill me in. X3 It's probably something blatant that I overlooked.)
Someone who unintentionally clicks on the "Do not display comments" link may wonder why no comments are displaying and/or may think that commenting is disabled on the entry.
Uhhhh... I can't think of any more drawbacks to this right now. I think the main one is the coding issue.

Fix community renaming.

2008-09-22T17:53:21Z

Title
Fix community renaming.

Short, concise description of the idea
Repair community renaming to work as documented: allow communities to be renamed [using a name] from an existing journal that you own.

Full description of the idea
Currently, communities cannot be renamed [using the name] from an existing journal - only using an unregistered name, or [the name from] a deleted and purged one.

The inability to rename communities in this way is an error that has occurred sometime between 2007-08-28 and 2008-02-19 as a result of some other change.
August 2007 was the last time i personally renamed a community [using another usename I owned.]
Feburary 2008 is the first time i've attempted to renamed a community since.
I recognise it may be hard to track down the exact cause of this based on these dates.

Livejournal support have assured me that there is nothing they can do to help

for those unfamiliar with renaming, here is the FAQ
and the renaming service itself

Issue tracking system reference: LJSV-236

An ordered list of benefits

Features following documented behaviour is good.
Leaving broken features broken looks bad.
Users waiting to rename journals for which they have already purchased tokens can do so.

An ordered list of problems/issues involved

Someone will have to find exactly which code change broke the feature.
Someone will have to repair both the broken code, and ensure that the other related code change still works.

Note: this post has been edited slightly since it was submitted.
- I have removed a block of text that justified this post - it is included as a screened comment.
- I have added links to the renaming FAQ and the renaming service
- I have reworded several things to aid comprehension, most notably the parts in square brackets.
- I have fixed the unordered list code.

MAKE LINK LIST FRIEND ONLY

2008-09-22T17:53:13Z

Title
MAKE LINK LIST FRIEND ONLY

Short, concise description of the idea
Is there anyway in the Future you would consider making it so only your friends can seee your links?

Full description of the idea
Hi i have an link list of all the stuff i wanna share with my friends the only problem is that ANYONE who goes to my livejournal can see and click on my links.
I have links to my work walls etc and i hate the fact in order to share my work with my friends i have to share it with everyone.

An ordered list of benefits

People who are your friends only can see your work so noone has the links to things you don't want to share with everyone.

An ordered list of problems/issues involved

none as i think it gives the user more control over who see's what.

Add HttpOnly flag to LiveJournal cookies

2008-09-22T17:53:06Z

Title
Add HttpOnly flag to LiveJournal cookies

Short, concise description of the idea
Add the HttpOnly flag to LiveJournal cookies to help prevent against XSS.

Full description of the idea
The only thing necessary is to set the HttpOnly flag on cookies sent by LiveJournal so that they cannot be accessed through client-side scripting. This makes executing XSS attacks substantially more difficult, and could potentially open the door to permitting third-party JS on LiveJournal pages some time down the road.

Modern browsers (Opera 9+, Firefox 3, IE 6.1+) support the extension, and browsers that don't support it will continue to operate as they did before.

Implementation instructions and more details are available by reading this post.

An ordered list of benefits

The security of LiveJournal users is enhanced
It's more difficult to execute XSS attacks involving LiveJournal
In the future, permitting external JavaScript is easier because it is known that no JavaScript can steal a user's cookies

An ordered list of problems/issues involved

I've read through a lot of LJ code and am reasonably confident nothing uses document.cookie, but if it does, implementing this option would break that.
It is possible to work around the restriction due to browser flaws at the moment, but as browser support improves, it makes sense to have LJ have the security options in advance.

suggestions @ 2008-08-27T16:15:00

2008-09-22T17:52:34Z

I was reading through the core layer and found a variable for determining if a viewer was logged in or not, and the comments suggested we make a link to the login page if they aren't. I took it a step further and made a simple login form, but ran into an interesting security issue.

function print_module_login() {
	if (not viewer_logged_in()) {
		open_module("login","login", "http://www.livejournal.com/login.bml");
		"""<form action='http://www.livejournal.com/login.bml' method='post' class='lj_login_form' class='pkg'>\n""";
		"""Username<input type="text" value="" name="user" size="15" maxlength="17" /><br>\n""";
		"""Password<input type="password" name="password" size="15" maxlength="30" /><br>\n""";
		"""<a href='http://www.livejournal.com/lostinfo.bml'>Forgot password?</a><br>\n""";
		"""<input type='checkbox' name='remember_me' id='remember_me' value='1' tabindex='4' />Remember me<br>\n""";
		"""<input name='action:login' type='submit' value='Log in' /><br>\n""";
		"""<a href='http://www.livejournal.com/openid/'>Login with Open ID</a><br>\n""";
		close_module();
	}
}

When I view the page with a login form on it (which is every page printed with Page::print();, which is every page in my layout), the word 'password' is removed from the type="password" portion of the input tag, leaving it as type="".

One can still enter their username and password to login, but the password is not covered by dots or stars by the client browser because the browser isn't being told it's a password field. The default type for unspecified fields is "text", which shows up in plain text, not masked.

For now, I have commented out the entire form in my S2 layout so the only thing that's rendered is a link to the login page.

open_module() and close_module() do nothing more than setup div containers with defined classes and titles, but if anyone feels the code in them is absolutely necessary, let me know and I'll post it as well.

I have two ideas to solve this problem.

Simple: Stop stripping "password" out as an input type. It has no effect on the server side of things, so it's not fixing any sort of possible security hole by being stripped. It is, however, providing the potential for "over the shoulder" password thefts.

Slightly Less Simple: Provide a builtin function in the core layer for providing a login form, probably via something akin to $p->login_form();.

During form submission, each input field is condensed down to a paired key and value. The key is the input field name (from the name="blah" portion of the input tag), and the value is whatever the user typed into the field (or alternatively, wa pre-entered via a value="whatever" portion of an input tag).

In GET requests, those key and value pairs end up looking like ?key1=value1&key2=value2 at the end of the URL.

In POST requests, those key and vlue pairs end up looking like

key1: value1
key2: value2

in the request header.

At no time during submission is there any mention from the client side to the server side regarding what type="" was in the input field. Having type="password" is no less secure than any other type, because the server has no idea what the type is; "type" is not a part of "key" or "value".

Fully supported LJ backup facility

2008-09-22T17:52:01Z

Title
Fully supported LJ backup facility

Short, concise description of the idea
There would be a utility fully supported by lj that would back up all user content held on the livejournal servers.

Full description of the idea
The idea is to provide a way in which a person entire content can be stored off the livejournal servers. This would do more than the existing back up utilities which extract only text. It would also lift off all voice posts, scrapbook photos, user pics, profiles, to do posts, etc.

An ordered list of benefits

* This would provide comfort to users that their data is safe. I was a member of a social networking site called www.facparty.com which had 7million users, but has mass deleted accounts following various issues and now has only 200,000. All my photos have now gone from that site.
* Based on the example of ljarchive(which backs up entries, but not other data) it would be easier to search for specific entries, information.

An ordered list of problems/issues involved

* Likely to be a difficult project, although lj archive's code would provide a useful starting point.