On Mon, Feb 2, 2009 at 10:11 AM, Thomas Charron <twaf...@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 thomaschar...@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.
_______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
