May 2nd, 2002

  • cryo


There -needs- to be a capabilities result returned at login.

The capabilities needs to tell the clients what protocols it can understand.

I don't want to have to try to make the user specify which version to use for whichever server they are currently using, because they have no idea if deadjournal or whatever has upgraded to whatever capabilities.

This can be a 32bit value that specifies version and other abilities or protocol changes.
This should probably also house lj_fastserver as a capability, since it's specific, more as a cleanliness issue.
amused, happy
  • mart

Journal-wide Security Setting

Lots of users want an option to convert all old entries with x security level to y security level, and this has been discussed lots of times before. I propose the following interim solution...

All accounts should have a "base security" setting. This setting allows choice between private, public and friends-only (not custom security, for simplicity's sake) and would for the most part be a simple matter of adding a check at the start of the journal view generator which refuses to output anything if the journal it relates to has a security setting which the remote user doesn't have access to. In addition to this, talkread and talkpost would need an additional check, and the friends view can simply read in the relevant userprop of all friends before starting and decide if each user's entries will be displayed or not and store it in a hash or some similar structure.

This security setting is more severe than standard security since it applies to the journal as a whole rather than to individual entries. It also does not change entry-specific security, so a post that was posted as public in a private journal will become public if that private journal is made public. This would have to be made clear in the place where this option is given.

Possible caveat put forward by ccupguy: Should community admins be able to set base security on communities which would thereby affect all posts to that community?

So... uuh... discuss, I guess.

Originally accidentally posted in my personal journal. It got three responses while there, all "yaying" the concept, with a reference to foreach_entry (which still hasn't been implemented after all this time) (mtffm) and a benefit that a journal could temporarily be made wholly friends-only while the user manually tweaks older entries en-masse before putting it back to public again. (jarel)