On 12/8/09 2:57 PM, Evan Prodromou wrote:
I've just pushed code to 0.9.x to support forwarding notices.
When user A forwards a notice created by user B, the notice is
distributed to all user A's subscribers (except those who've already
received the notice, and those who've blocked user B). A record is
stored that A forwarded the notice. This is not a new notice, so it's
not listed anywhere else but inboxes.
When a user's inbox is shown, each notice that was received because it
was forwarded is marked "Fwd" (this could be better!) and a list of
users who forwarded the notice is put at the end of the notice. There's
also a form to forward the notice (if you haven't before, and if you're
not the author).
There's still a lot to do here, but I think we've got the basics for the
"retweet" functionality covered.
The UI presentation can be worked out... my main worry is that this just
doesn't do what I'd expect "forwarding" to do. As a user it confuses the
heck out of me; it shatters so many expectations that we had to poke
around in channel for about 20 minutes before I even figured out what
was going on.
This system is much more like Facebook's "like" than it is like
forwarding e-mail; it's pretty much limited to you and your local
subscribers, stops at the site boundary. The only thing we'd need to add
is a counter of how many people forwarded any given notice.
It looks like we've got a major problem with our mainstream methods of
reading, though, because notices you've gotten via forwarding appear in
the timeline according to their original posting date, not when they
were forwarded:
* Reading on the web, a new forward won't be up at the top of your
timeline. If it's an older notice, it might be many pages deep in the
list and you'd never think to look for it.
I also don't think they'll show up in the realtime updates; no new
notice ID means nothing in the notice queue for the plugin to pull from.
* Many Twitter API clients check for *new* notices since the last one
they saw; even if the original was recent, you may never see a forward
if your client already refreshed between the posting time and the
forward time. (Confirmed in Adium 1.4b and Tweetie 2/iPhone.)
Those could be fixed if we save the forward timestamp instead of the
original post timestamp into the inbox; new forwards would appear at the
top of peoples' inboxes and would become accessible to client software
again.
Further, your forwards won't make it all to any of these places:
* Local subscribers reading via XMPP
* Local subscribers reading via SMS
* OMB remote subscribers
* Twitter bridge
* Facebook bridge
* your profile timeline
* your profile's RSS or Atom feed
* your "and friends" timeline if you're subscribed to the original poster
If we want to stick with it for compat with Twitter's new ReTweet, we
might want to give it a clearer name (probably the main reason that it's
been so controversial is that it's conceptually totally different from
the forwarding that people have been doing manually under that name).
-- brion
_______________________________________________
StatusNet-dev mailing list
[email protected]
http://lists.status.net/mailman/listinfo/statusnet-dev
