Oct. 1st, 2012

[personal profile] alexbayleaf

Get rid of restrictions on future-dated posts


DW doesn't allow you to post a future-dated post, and then follow it with a present-dated post. There are probably other restrictions along these lines. I suspect they are all there for historical reasons that don't matter any more, and I propose we get rid of them.

I came across this bug when crossposting from my Wordpress blog using JournalPress. My Wordpress blog (and my DW, for that matter) both have their timezones set as Australia/Melbourne, which as you probably know is almost as far in the future as it's possible to be without being a hobbit. So, I posted post A from my wordpress blog, and it was crossposted. Then I went to post another post, locked to my access list, directly on my DW. I was greeted with this error message:

<blockquote><strong>Error updating journal:</strong> Incorrect time value: You have an entry which was posted at 2012-10-01 02:02, but you're trying to post an entry before this. Please check the date and time of both entries. If the other entry is set in the future on purpose, edit that entry to use the "Don't show on Reading Pages" option. Otherwise, use the "Don't show on Reading Pages" option for this entry instead. </blockquote>

Initially I was going to submit some kind of bug report, but then I got to thinking... why is this limitation there at all? It has the whiff of something that was done for historical reasons, back in LJ's early days, and hasn't been revisited.

Why do we care about future-dated posts anyway?

Before sticky posts, people used to post future-dated posts (eg. dated 10 years in the future) so they would always show up at the top of their journal. This has been superseded by the sticky post feature, though I suspect some people may still use the old technique.

<user name="azurelunatic">, on IRC, suggested that it might also have something to do with people's computers having really wacky times set on them. I can see this being a problem a decade ago, but I think almost everyone's computer these days using <a href="http://en.wikipedia.org/wiki/Network_Time_Protocol">NTP</a> to automatically set the time, yes? So this would be a much rarer thing than it used to be.

I don't actually have a good feeling for what the solution is here, but I wanted to raise this suggestion to ask:

1) what benefit is there to limiting posting in this way?
2) do those benefits still apply, or are they historical only?
3) can we just get rid of it?
4) if not, can we modify it so that only egregious badness is prevented, but posting from a third-party client in another timezone is permitted?

For the purposes of voting, please consider the suggestion to be "get rid of future-date limitations on posts to the greatest degree possible."

Poll #11813 Get rid of restrictions on future-dated posts
Open to: Registered Users, detailed results viewable to: All, participants: 56

This suggestion:

View Answers

Should be implemented as-is.
24 (42.9%)

Should be implemented with changes. (please comment)
7 (12.5%)

Shouldn't be implemented.
10 (17.9%)

(I have no opinion)
13 (23.2%)

(Other: please comment)
2 (3.6%)

kaberett: Overlaid Mars & Venus symbols, with Swiss Army knife tools at other positions around the central circle. (Default)
[personal profile] kaberett

"This post will self-destruct shortly...": automated security changes

privacy, filters

People commonly make public posts which they do not wish to remain public indefinitely. An additional field at posting ("Change security [...] to [...] when [...] (has/have) elapsed") would remove the need to remember to make the manual change at a later date.

I repeatedly come across cases where people make a post with the specific intention of subsequently changing its visibility, for example:

(1) person with username A changes it to B. They want to flag this up to their subscribers, without creating a permanent trivially-findable public record. They make a public posting, intending to manually restrict access to said post after a week. Memory proves to be a tricksy beast, however.

(2) person wants their "current" entries to be public - on a rolling basis. That is, they *don't* want their entire journal to be public, but *do* want their initially-set-as-public posts over the last N weeks to be generally visible.

(3) person is making a links round-up (LRU); realises they've left out a link; edits the original post to include it. In order to flag this up to people who've already read the LRU and won't read closely again, they make a follow-up post to appear on people's dwrolls, highlighting that they've added a new link, with the intention of deleting the follow-up post after a few hours (at which point it is obsolete, because people who're only just catching up with their reading lists won't have seen the pre-edit LRU anyway!)

In each of these cases, it would be helpful if there were the option tree at point of posting:

Change security at later date? Y/N
Change security to? [pre-defined set of access filters, etc!]
Change security when? [hours, days, weeks...]

... such that in case:

(1) person, at time of posting, can say "make this post access-locked after a week"
(2) user can set a default behaviour of "increase privacy of all posts to [LEVEL] after a month" (where custom filters, etc obviously don't have their privacy level *reduced*!)
(3) user can make the post automatically set itself private e.g. 6 hours after initially posting

In IRC we briefly discussed the possibility of actual self-destruct - i.e. automatic deletion after a set time frame - but consensus there was that auto-deletion is an undesirable behaviour, because (a) deletion is irreversible, and (b) setting posts to private has the same effect on the reader as deleting them.

In terms of downsides, the only one that springs out at me is that - at least for my level of familiarity with the code-base - this would be an absolute *swine* to implement. However, I am very open to hearing other criticisms :-)

Poll #11815 "This post will self-destruct shortly...": automated security changes
Open to: Registered Users, detailed results viewable to: All, participants: 64

This suggestion:

View Answers

Should be implemented as-is.
25 (39.1%)

Should be implemented with changes. (please comment)
10 (15.6%)

Shouldn't be implemented.
13 (20.3%)

(I have no opinion)
15 (23.4%)

(Other: please comment)
1 (1.6%)


Dreamwidth Suggestions

April 2017

23456 7 8
9 101112131415

Style Credit

Expand Cut Tags

No cut tags