Crosspost to Facebook Notes

[thorfinn]

Title:
Crosspost to Facebook Notes

Area:
crossposting

Summary:
The crossposter sites option should have an option to "push" notes into facebook.com.

Description:
Facebook.com currently has a Notes feature. You can point it at a public RSS feed to import notes, but that fails to re-import edited notes.

I would prefer to "push" notes into facebook via the crossposter, so that edited notes show up correctly etc.

That may or may not be technically possible to do with facebook's note posting. I suspect it would require some reverse engineering of facebook page code etc.

There are complications around posting security - facebook does actually have the concept of custom posting security, and an extra "friends of friends" level.

Also I'm pretty sure there's no way to prevent comments on a note within facebook, so this option may be problematic.

Poll #3653 Crosspost to Facebook Notes

Open to: Registered Users, detailed results viewable to: All, participants: 53

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
14 (26.4%)

Should be implemented with changes. (please comment)
2 (3.8%)

Shouldn't be implemented.
20 (37.7%)

(I have no opinion)
17 (32.1%)

(Other: please comment)
0 (0.0%)

Comments

[zvi]

If Facebook supports a crossplatform posting API (like metaweblog) then I think we should support it. If it's a facebook idiosyncratic API, then I'm not sure it's worth it.

[thorfinn]

Depends on what the reasons for considering it "worth it" are. It will be a facebook idiosyncratic API, that is pretty certain. That API is fairly simple though - some cookie auth, and a web form or two to scrape.

If we're counting "number of people who might use it" as a worth it measure, then, well, like it or not, Facebook has a very huge number of people on it. Yes, the intersection between FB users and DW users is probably not immense... but any other weblog APIs also have a pretty small intersection, I suspect.

There is of course a risk of FB changing it, resulting in the feature stopping functioning until it's fixed - but I haven't seen that particular chunk of FB change much.

[zvi]

I think Dreamwidth should focus on open standards and protocols, that promote generic interoperability, and allow new players to take advantage of whatever we build just by following the standard.

Just about everything with Facebook is Facebook specific. I don't think we should get into the making Facebook better business.

[thorfinn]

*nod* Fair enough!

[matgb]

Except...

Facebook is one of the biggest supporters of Open Source out there at the moment, most importantly memcache, but a whole host of other things.

IIRC, they rejected OpenID as a platform for the simple reason that the UX sucks, big time, and wasn't likely to improve anytime soon, so they created Connect partially as a challenge to OpenID to get its act in gear.

OpenID has had no serious development since 2007. The UX still sucks. Facebook connect, OTOH, is dead easy, dead effective, and very useful. I use it to comment on various blogs fairly regularly.

I agree that specific site coding isn't necessarily a good thing, but Facebook is so massive, and open source projects in general, and OpenID as a specific, could learn masses from their commitment to a good user friendly experience.

Sure, there are many many flaws with it, but some of it is really really well done.

[zvi]

I will assume, for the sake of argument, Facebook Connect is easier to login to than OpenID. (I have never had a Facebook account.) That doesn't change the fact that you can only use it to login with a Facebook account.

I don't think we should be in a "make your [non-Dreamwidth] account more useful" business, which I think building code to let you login from one particular website, or repost to one particular website, is. I'm not hostile to Facebook. I'd like us to move away from LJ-interoperable tools into more generally web interoperable tools, for instance.

But, I'm also not convinced by, "Half the internet has Facebook accounts" arguments, because there's no way to know when a quarter of the internet will start abandoning their Facebook accounts. Remember when Myspace was The Social Network? Now, it's what bands use instead of building a real website.

[thorfinn]

The Internet always moves on... but I don't get the impression that the Internet is going to abandon Facebook any time soon. In very large part because of their UX, and the fact that they actually do adapt it to fit changing contextual conditions.

FB engineering clearly has a serious clue. Have you even heard whispers of a facebook outage? I haven't, and it would be all over the media if there was one. Twitter, on the other hand...

That's actually the same reason I'm here rather than on LJ - DW development actually has a serious clue and is set up to retain that clue, LJ development clearly doesn't any more, and that's my professional opinion as a software engineer/architect.

Don't get me wrong - Facebook certainly have some dodgy practices going on in the sense that they're an ad supported company, so it's in their interests to keep data flowing the advertisers way. That's a business model disagreement, and a lot of people may not like it, but ultimately, they're conducting a legal business (now that they've sorted out some privacy controls to fit a variety of privacy legislation), using pretty much exactly the same business model as Google.

The question for DW is not "should DW be helping other companies". That's got nothing to do with it.

The questions should be "would providing this functionality be in the interests of DW and its membership?" and "is the cost of creating and maintaining the functionality too high?"

For this poll, I think the answer is "yes, a little bit" and "at the moment it's too high, but maybe not if the crossposter is refactored a lot to support multiple different APIs".

With regards to a hypothetical FB Connect/Twitter OAUTH poll, I think the answer is "maybe" (primarily because OpenID actually does suck to use, I know DW is trying to improve it, yes), and the implementation work isn't immense.