Suqashing Facebook (WAS: Conducting GNHLUG business on Facebook (was Stop! Unix Time))

[Arc Riley]

On Mon, Feb 2, 2009 at 10:11 AM, Thomas Charron <twaffle at gmail.com> wrote:

 What's at issue is that the meaning of data is still left as an
> interpretation to the student.  Yes, you can shove arbitrary data and
> publish that data.  That data still needs to be adopted as a standard
> by everyone.  As an example, connect to google chat using PSI IM, and
> go ahead and try to get notifications when you have new emails.


IIRC, PSI does not fully implement XEP-0060, or even the "personal eventing"
subset of pubsub defined in XEP-0163.  Pidgin also has quite poor XMPP
support.  Of course this doesn't matter - if a client doesn't support a
feature the service can detect that and fallback to a less elegant solution,
such as sending you an XMPP message to remind you of an event you RSVP'ed
for.

The beauty in this is you don't even need a XMPP client running on your
machine to access this data.  If you have a client that understands the
required extensions in a way that makes it useful to you, you can use your
own client, or you can use a website that implements it - ie, just as you
have a wiki account for gnhlug.org, you could have a
ThomasCharron at gnhlug.org JID used only for the website gateway.  To you, a
user of the website, XMPP support doesn't matter regardless if the XMPP is
being run on the website backend or in your browser via a javascript client.

Client support for extensions follow demand, so as such services come into
mainstream the mainstream clients will support them.  At that point you can
use a single JID for everything.



>  The crux of the complain is, however, that you have to authenticate
> with facebook.


No you don't.  There are many facebook apps that exist solely to provide
facebook users access to offsite data (and vice versa).

Take for example the roommate searching app.  It's actually being run by a
3rd party website that's been running that service for awhile - all the
facebook app does is provide access to that data via facebook.  They could
have taken it a lot further, such as when you post a "looking for apt" ad on
their site, it could show "Thomas Charron is looking for a new apt on
RoommateSearchPlus!".

Similarly, if you wanted to run a Meetup-type site targetting free software
oriented groups, you would host the site on your own, expose an XMPP service
to it (or even run the whole site's backend via XMPP - better than RPC!),
and tie it into Facebook via their API so people who post events or RVSP to
them have that status showing up on their Facebook pages as well.  This
doesn't force your entire member base to sign up for Facebook accounts in
order to RVSP, just provides a way for Facebook users to help publicize the
event to other Facebook users.

Most of the libraries for Facebook API is free software.  There is no reason
not to write and implement Facebook apps on the basis of software freedom
ethics.  If you want to boycott Facebook based on them being a business that
derives profit from advertising, that's your choice, but many of us find
it's a useful tool.


 Nothing in XMPP forces anyone or anything to actually share data
> over the wire.  And many would suggest it's actually a bad idea to
> open it all up to external, potentially untrustworthy, JIDs.  In the
> world of federation, you have to trust the remote servers.  With wide
> scale adoption of XMPP federated servers, you potentially run the same
> risks as MySpace, but with no central lockdown point any longer.


Server federation isn't unauthenticated.  There's a process requiring signed
certs free, via xmpp.org, requiring verification of domain ownership only.

Information, specifically presence and eventing, is provided on an
permission-authorization basis.  For example, your status (ie, offline,
away, available, etc) is only given to other XMPP users you've authorized.

This is how your roster is populated (aka buddy/friend list) and this same
mechanism is used to manage who's authorized to send and will receive data
from service nodes (ie, chat rooms, group calendars, etc).


 Think I'm wrong?  Example.  Suuuuuure, you can disallow any traffic
> from anyone NOT on your contact list.  However, how do they get there?
>  They request to be there.  Guess what's added to that?  A message!
> Hrm..  Sounds like Spam 2.0 to me!  :-D
>

Except given domain certs, unlike email spam, you cannot mask your source
domain.  If some dude in China federated his own server and started spamming
everyone, poof, there goes his federation status.

Email spam is typically sent from compromized windows computers running on
IPs which don't have control of their reverse dns or ownership of their
domain - both of which are required for the domain cert.  It's going to be
awhile until everyone has their own 64-bit IPv6 subnet and reverse DNS
becomes "easy" again, at which point I'm certain additional precautions will
be in place.

Moreso, your argument reads akin to "we shouldn't have a mailing list,
because if it becomes popular, spammers will use it".  I'm of course not
arguing that GNHLUG needs a mailing list, I'm only pointing out that SMTP
exists and is used for doing so, vs building a one-shot forum site that
don't use existing standards in their exchange of data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20090203/3cfd3329/attachment.html