Re: Suqashing Facebook (WAS: Conducting GNHLUG business on Facebook (was Stop! Unix Time))
On Tue, Feb 3, 2009 at 9:35 AM, Thomas Charron wrote: > > Your example is slightly counter to your argument. The thought put > forth is that everyone can run a server of their own, with their own > web sites, etc. So I'd be thomaschar...@kilomonkies.com. And how is > gnhlug.org going to know I'm me when I say, visit the web site? I think some wires got crossed between what David originally posted and my response. I'm not suggesting everyone run their own server, that's a non-starter. Facebook is used because it's free and takes seconds to setup. I'm likewise not advocating for boycotting Facebook, that's also a non-starter. You never change anything by fighting the existing reality. I'm suggesting different services run by different groups - cooperative competition. Doesn't matter which service you're using, the data all ties together. I see the primary disfavorable element of Facebook is it's a monolithic service. I see decentralized, compatible services as the new paradigm that's going to make the existing paradigms obsolete. Facebook will, of course, adapt and evolve to this new paradigm. So, how is this facebook applet going to authenticate with an > external server? After all, I may want to schedule some private > events I don't want everyone to see. Facebook apps are hosted on 3rd party servers. *You* run the applet code on *your* server. Some people use Facebook's authentication database solely, others have their own auth database with a field that provides the facebook userid for known users, adding new users when facebook users add your app to their account. I've looked into writing an Ohloh app for Facebook. Ohloh has an open API, so does Facebook, and I as a third party need "control" over neither authentication domains to link the two - just the ability in both APIs for users to verify that they own a certain account (they both do). Presto, Ohloh user data aggregated to Facebook such that the rewards system in the prior is advertized in the latter, thus amplifying the ego encouragement effect Ohloh provides. > Facebook tie ins to other sites require an inferred level of trust > of facebook themselves. But your right, I choose not to use it as a > tool, no use in arguing the merits of the company. Actually it's a level of trust by users, and of course it can and has been abused. Every Facebook user must authorize any specific app to access their data. Users are told, by Facebook, very explicitally that their personal information will be shared with the 3rd party app if they authorize the app. This is an inherit disfavorable element of monolithic service models like Facebook - you either don't allow 3rd party apps, or incur the expense of verifying the 3rd party code and hosting on your server, or defer to your users the responsibility to verify trustworthyness of 3rd party app hosts when giving them access to all their data. As an example, livejournal is the 'original' social networking site. > It's still there. And a long, long time ago, it added XMPP support. > What problems did it solve? Nada. Was it cool, and neat? Yup. > Could it be used to integrate livejournal into MY site? Yup. Did > people WANT that? Nope. I argue that the time hasn't come yet. I don't see the value being primarily in most users wanting to connect to livejournal directly using XMPP, or that users put value in XMPP themselves, but that XMPP can be used as an alternative to RSS/Atom/etc to aggregate data between different sites more efficiently. I've never argued XMPP as a "magic bullet". What I'm proposing is that XMPP is the best communications framework for building a new social networking paradigm capable of obsoleting the existing "walled garden" social network paradigm used by MySpace, Meetup, Facebook, etc. Now, what are Joe and Jane to do? Well, they complain to ubah > portal, right? Ok, so the portal blacklists gnhlug. Perhaps they > request their certificate by revoked (I'm not so sure this has *EVER* > occured thus far). The infrastructure isn't in place to deal with this issue because it's currently a non-issue. This is like arguing against IRC back in the late 80's because some people could use it to spam messages to channels. A bigger issue of course, and one unforseen at the time, is DoS attacks becoming such a problem that many hosting services (such as mine, ServerBeach) would have to ban IRC use as a whole - no servers, no bots, no clients running under GNU Screen. XMPP is a lot more robust than email, IRC, or RSS feeds. I'm not saying it's foolproof, no communication system is foolproof. I have seen quite a bit of work going into making sure it doesn't become a problem and I'm confident that the community will solve remaining loopholes /as they become problems/. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Suqashing Facebook (WAS: Conducting GNHLUG business on Facebook (was Stop! Unix Time))
On Tue, Feb 3, 2009 at 4:41 AM, Bill McGonigle wrote: > On 02/02/2009 12:35 AM, virgins...@vfemail.net wrote: >> Instead of >> hosting a Web site in order to host a Web site, people are putting >> "pages" on third-party services like Facebook. > Most people don't want websites, actually. They want to share photos > and prose with their friends. Fewer still want to talk to everybody, > and there are hosted blogging sites for that. Way down the list is > people who need their own websites anymore, and most of those people > want a CMS. *BinGo* People want the service, not the technology. >> In addition, most of these "services" are mutually incompatible. For >> example, Myspace and Meetup can't talk to each other. > I don't know which ones are participating today, but OpenSocial was > designed to fix this. I thought it was everybody-but-Facebook now, but > I'm not paying close attention. Tom, this and a Facebook app might help > your scenario. And no one ends up caring. Because it's awkward. They look at it, and using those particular clients always presents a less rich environment then going to the site they like itself. -- -- Thomas ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Suqashing Facebook (WAS: Conducting GNHLUG business on Facebook (was Stop! Unix Time))
On Tue, Feb 3, 2009 at 1:56 AM, Arc Riley wrote: > 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. As the original example showed, it can even control a toaster. :-D But there's no paradigm shift there. JSON could also control a toaster, given a specification. But I digress. Your example is slightly counter to your argument. The thought put forth is that everyone can run a server of their own, with their own web sites, etc. So I'd be thomaschar...@kilomonkies.com. And how is gnhlug.org going to know I'm me when I say, visit the web site? >> 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). I'll be totally honest, I'm totally ignorant of it. As others have said, ANYTIME I see ANYTHING to do with facebook it stares at me with a big phat login page. And I press that big phat 'X' close the page button. > 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!". Show me an example. I've never seen one that didn't eventually try to suck me into facebook. I'm not saying they aren't there, I just haven't seen any. > 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. Nice solution. There does seem to be that side effect that most of these social networking sites tend to take to take those sort of things that are successful, embrace them, and squash them for their own means. Anyhoo.. So, how is this facebook applet going to authenticate with an external server? After all, I may want to schedule some private events I don't want everyone to see. > 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. Facebook tie ins to other sites require an inferred level of trust of facebook themselves. But your right, I choose not to use it as a tool, no use in arguing the merits of the company. >> 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. Which only currently functions for free due to limited demand. xmpp.org will not scale that high. They have an extremely limited amount of resources. Additionally, they aren't really doing anything at all. http://www.startssl.com/ is. It's technically part of startssl.org and their 'web of trust' notary concept. It remains to be seen if it gained a much wider audience if it would remain free. Your trust in the federation is now being placed on startssl.com. >> Think I'm wrong? Example. Suure, you can disallow any traffic >> from anyone NOT on your contact list. However, how do they get there? >> They request to
Re: Suqashing Facebook (WAS: Conducting GNHLUG business on Facebook (was Stop! Unix Time))
On 02/02/2009 12:35 AM, virgins...@vfemail.net wrote: > Instead of > hosting a Web site in order to host a Web site, people are putting > "pages" on third-party services like Facebook. Most people don't want websites, actually. They want to share photos and prose with their friends. Fewer still want to talk to everybody, and there are hosted blogging sites for that. Way down the list is people who need their own websites anymore, and most of those people want a CMS. > In addition, most of these "services" are mutually incompatible. For > example, Myspace and Meetup can't talk to each other. I don't know which ones are participating today, but OpenSocial was designed to fix this. I thought it was everybody-but-Facebook now, but I'm not paying close attention. Tom, this and a Facebook app might help your scenario. > If there was some kind of ready-made, drop-in, easy-to-use FOSS > replacement for these services that could be plopped on any old > hosting service The Facebook software isn't where their value is. The value comes from the Network Effect they generate and their centralized authentication and authorization systems. Yeah, a self-hosted XMPP solution with an x.509 certificate chain could confederate something like this. But, ouch. And the system you propose confers obligatory cost on the user, while Facebook doesn't. 'No-obligatory-cost' is a major ingredient for success with web services. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 b...@bfccomputing.com Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Suqashing Facebook (WAS: Conducting GNHLUG business on Facebook (was Stop! Unix Time))
On Mon, Feb 2, 2009 at 10:11 AM, Thomas Charron 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. Suure, 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 i
Re: Suqashing Facebook (WAS: Conducting GNHLUG business on Facebook (was Stop! Unix Time))
On Mon, Feb 2, 2009 at 12:35 AM, wrote: > The whole facebook/meetup/myspace/ > mess seems to be the product of a number of factors: > (1) People want web presence with prefabricated features like > calendaring, blogging, guestbooks, voting, and messaging. > (2) People want to network their content with other > people/sites/pages. > (3) Most people lack the technical knowledge/skills/resources to do > these things on their own. Your missing one huge fact here. Even if people have the knowledge, most people don't WANT to. Most people don't even make their own FOOD anymore, what makes you think they would ever want to build their own web sites, or orginize their own data? > It's probably fair to say that most of the folks on this list either > know, or could easily figure out, how to build and host their own web > site. Indeed, objectives (1) and (2) can and have been achieved this > way for many years. Building sites with one's desired features and > linking them to/from other sites IS exactly what the WWW is all about. It doesn't extend to that scale. The macro view of the network does not apply to the micro. There are issues with applying it to the micro, in that your new 'microsite' is now fending for itself on equal footing with macrosites. Then, some cert advisory causes your little microsite to stab you in the back, revealing your data, and worst of all, be utilized to atack your friends microsites. There are construction laws which affect every single home in the united states. Unless you advocate the policing of individuals servers in a simular manner, then you cannot make the comparison between what you CAN do and what you SHOULD do. > The average Joe, however, isn't a member of his local LUG. :) Most > folks don't know how to, or don't care to, build their own Web site. > This has caused people to flock to prefab pseudo-site services like > Myspace, Facebook, etc. By that logic, again, people go to McDonalds NOT becouse they like it, or because it's convienient, but becouse they don't know HOW to cook. > This mass migration to McWebsites completely disregards one of the > fundamental features of the Web: the heterogeneous, distributed nature > of the WWW. This, personally, has me quite concerned. Instead of > hosting a Web site in order to host a Web site, people are putting > "pages" on third-party services like Facebook. [Enter Mr. > Homogeneity stage left.] Of course, there's also the standard set of > security and reliability arguments for and against remote hosting of > live data. And the propsed solution to the issue is.. *drumrool please!* To homogonize all of the data in such of a way that people can freely share their data publically with everyone else. > In addition, most of these "services" are mutually incompatible. Note, incompatible isn't the word your looking for. The word is what you quoted above. 'Heterogenouse'. Placing my data on one site doesn't cause another not to work or function. They are all compatible on the internet. > For > example, Myspace and Meetup can't talk to each other. Add to that the > possibiliy that your hosting service might "lock down" access (whether > that means "logging in" to access a Facebook page or paying a > recurring fee to host a Meetup group), and the online community has > both serious practical and philosophical problems. What problems? Are you suddenly barred from using the internet? Or are you just annoyed that no one else wants to pay for you to freely use their service without you paying in any way, shape, or form? Note, paying isn't always cash. Sometimes, it's ad veiws, targetted spam, etc.. And don't make the comparison that information wants to be free. Sure, information wants to be free. However, even if your public library is offered to you for free doesn't exempt you from having to pay taxes to support it, and it CERTAINLY doesn't require that the library then also provide free parking. > Now, here's the FOSS solution I was thinking about! > Objectives (1) and (2) can both be achieved using existing FOSS. This > problem's Achilles' heel is (3). > > If there was some kind of ready-made, drop-in, easy-to-use FOSS > replacement for these services that could be plopped on any old > hosting service, then the problem posed by (3) could be solved. > People would be able to host their OWN sites, and wouldn't be forced > to use mutually incompatible pseudo-hosting solutions like Facebook. Where's yours? > Technically, this could be done a number of ways. Off the top of my > head... > (1) With a suite of PHP scripts that could be installed on any > hosting service that supports PHP (not hard to find). Supported and maintained by who? > (2) By installing a special package on a Linksys router. MMmmm.. New bot targets... Nummy.. Maybee now's the time to start writing Linux worms to infect these, and find nefariouse ways to use your personal da
Re: Suqashing Facebook (WAS: Conducting GNHLUG business on Facebook (was Stop! Unix Time))
On Mon, Feb 2, 2009 at 2:37 AM, Arc Riley wrote: > That's hilarious! But jokes about PHP scripts and internet appliances > aside, there *is* a real solution to this that's already accepted by the > community at large. > It's called XMPP - eXtensible Messaging and Presence Protocol. > Thanks to Google and Livejournal there's already a huge userbase. It's > inter-server, so all those @gmail.com users can use any federated XMPP > service, and federation is easy. XMPP is a technology to assist in the distribution of data. It can be used to assist in the interchange of data however a grail it is not. > Many services already offer XMPP access to their data, especially > microblogging services like twitter and identi.ca. It doesn't matter what > XMPP server you connect to (ie, gmail.com). If a feature isn't already > supported by XMPP you can write an extension. Thanks to existing and > well-deployed standards like pubsub > (http://xmpp.org/extensions/xep-0060.html) many new services don't need to > extend XMPP for their new functionality. 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. > Facebook has flirted with XMPP in the past, they're currently planning to > add support just for Facebook IM. There are already a number of XMPP > gateway apps for Facebook hosted by 3rd parties. In Facebook's defense, > they have an open API and allow anyone to host Facebook apps on their own > servers that can access user's information and which have equal access to > publish snippets to friend's pages. There are many libraries to work with > Facebook's API. The crux of the complain is, however, that you have to authenticate with facebook. > So a new model capable of obsoleting the existing paradigms, being as it > must interoperate, is best implemented as XMPP service software. 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. Don't get me wrong. Sharing data via XMPP can be a great thing. But it is *NOT* the cure. The internet is primarily built around the idea of the routing of anyones data, in any way possible. XMPP is the SMTP of XML snippet routing. There is no concept of authentication of data in the world of the giant IPv4 network which has grown to be known as the internet. And that has allowed it to flurish. Minus some utopian identification service which can be trusted 100%, no technology will solve the issue. As part of that, the more XMPP is utilized, the more issues which crud up other protocol spaces will migrate there. Think I'm wrong? Example. Suure, 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 -- -- Thomas ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Suqashing Facebook (WAS: Conducting GNHLUG business on Facebook (was Stop! Unix Time))
>(1) With a suite of PHP scripts that could be installed on any > hosting service that supports PHP (not hard to find). >(2) By installing a special package on a Linksys router. >(3) Developing an embedded Linux Internet appliance to host from a > user's home/office connection. (What, my ToS say "no servers"?) I think that the amount of information that most people have on Facebook, etc. and the number of times it was accessed would probably not cause issues with most people's providers. But Facebook and its ilk provide three services, one of storing your information, one of easily allowing others to find it, and one of blocking most of those people from bothering you if you do not want them to. (3) would easily solve the "storing" problem, but you would still need some searching and blocking apparatus. Probably make a good topic of conversation on Friday the 13th. md -- Jon "maddog" Hall Executive Director Linux International(R) email: mad...@li.org 80 Amherst St. Voice: +1.603.672.4557 Amherst, N.H. 03031-3032 U.S.A. WWW: http://www.li.org Board Member: Uniforum Association Board Member Emeritus: USENIX Association (2000-2006) (R)Linux is a registered trademark of Linus Torvalds in several countries. (R)Linux International is a registered trademark in the USA used pursuant to a license from Linux Mark Institute, authorized licensor of Linus Torvalds, owner of the Linux trademark on a worldwide basis (R)UNIX is a registered trademark of The Open Group in the USA and other countries. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Suqashing Facebook (WAS: Conducting GNHLUG business on Facebook (was Stop! Unix Time))
That's hilarious! But jokes about PHP scripts and internet appliances aside, there *is* a real solution to this that's already accepted by the community at large. It's called XMPP - eXtensible Messaging and Presence Protocol. Thanks to Google and Livejournal there's already a huge userbase. It's inter-server, so all those @gmail.com users can use any federated XMPP service, and federation is easy. Many services already offer XMPP access to their data, especially microblogging services like twitter and identi.ca. It doesn't matter what XMPP server you connect to (ie, gmail.com). If a feature isn't already supported by XMPP you can write an extension. Thanks to existing and well-deployed standards like pubsub ( http://xmpp.org/extensions/xep-0060.html) many new services don't need to extend XMPP for their new functionality. Facebook has flirted with XMPP in the past, they're currently planning to add support just for Facebook IM. There are already a number of XMPP gateway apps for Facebook hosted by 3rd parties. In Facebook's defense, they have an open API and allow anyone to host Facebook apps on their own servers that can access user's information and which have equal access to publish snippets to friend's pages. There are many libraries to work with Facebook's API. So a new model capable of obsoleting the existing paradigms, being as it must interoperate, is best implemented as XMPP service software. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Suqashing Facebook (WAS: Conducting GNHLUG business on Facebook (was Stop! Unix Time))
> Date: Sun, 1 Feb 2009 21:46:31 -0500 > From: Arc Riley > I'm tired of hearing people in the free software community whine about > Facebook. There are a lot of programmers on this list. If you feel > passionately enough about this to complain then let's build an alternative. I haven't been whining about Facebook (admittedly, it's VERY tempting), but I've recently been thinking about this problem, in a somewhat broader sense. The whole facebook/meetup/myspace/ mess seems to be the product of a number of factors: (1) People want web presence with prefabricated features like calendaring, blogging, guestbooks, voting, and messaging. (2) People want to network their content with other people/sites/pages. (3) Most people lack the technical knowledge/skills/resources to do these things on their own. It's probably fair to say that most of the folks on this list either know, or could easily figure out, how to build and host their own web site. Indeed, objectives (1) and (2) can and have been achieved this way for many years. Building sites with one's desired features and linking them to/from other sites IS exactly what the WWW is all about. The average Joe, however, isn't a member of his local LUG. :) Most folks don't know how to, or don't care to, build their own Web site. This has caused people to flock to prefab pseudo-site services like Myspace, Facebook, etc. This mass migration to McWebsites completely disregards one of the fundamental features of the Web: the heterogeneous, distributed nature of the WWW. This, personally, has me quite concerned. Instead of hosting a Web site in order to host a Web site, people are putting "pages" on third-party services like Facebook. [Enter Mr. Homogeneity stage left.] Of course, there's also the standard set of security and reliability arguments for and against remote hosting of live data. In addition, most of these "services" are mutually incompatible. For example, Myspace and Meetup can't talk to each other. Add to that the possibiliy that your hosting service might "lock down" access (whether that means "logging in" to access a Facebook page or paying a recurring fee to host a Meetup group), and the online community has both serious practical and philosophical problems. (Thank you, Arc, for the gripeortunity...) Now, here's the FOSS solution I was thinking about! Objectives (1) and (2) can both be achieved using existing FOSS. This problem's Achilles' heel is (3). If there was some kind of ready-made, drop-in, easy-to-use FOSS replacement for these services that could be plopped on any old hosting service, then the problem posed by (3) could be solved. People would be able to host their OWN sites, and wouldn't be forced to use mutually incompatible pseudo-hosting solutions like Facebook. Technically, this could be done a number of ways. Off the top of my head... (1) With a suite of PHP scripts that could be installed on any hosting service that supports PHP (not hard to find). (2) By installing a special package on a Linksys router. (3) Developing an embedded Linux Internet appliance to host from a user's home/office connection. (What, my ToS say "no servers"?) Any other ideas? Does anyone know of projects (current or planned) to fill this niche? > Date: Sun, 1 Feb 2009 22:34:21 -0500 > From: Peter Dobratz > I learned that I missed out on the 10-year high school reunion. I > had updated my contact info on the official alumni site, but I > hadn't joined Facebook, so they couldn't find me. That's just the problem. Facebook is a poor substitute for the real world. If I were trying to find my classmates, my alumni association would be the FIRST place I'd look. > Of our graduating class of 270, 124 are members of Facebook. "If an item doesn't appear in our records, it does not exist!" -- Jedi Archives librarian to Obi-Wan Kenobi ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
