Current social networking sites are islands.  This makes about as much sense as the very early email services, which offered delivery only among their own customers.  Very handy if it's all you've got, and a required early step, but we can do better.

There is a move afoot for these sites to export FOAF data for their users.  This is an improvement, but is analogous to AOL or MSN offering enhanced functionality for and among its users, in an attempt to lock in customers.  It will be preferred by some, perhaps many, but is by no means the only model.

The mature form of social networking won't require a monolithic intermediary.  It will look like email.  Distributed, ubiquitous, heterogeneous, and standards-based.  Web servers will deliver FOAF files, users will control who can see which data through flexible permissions schemes, requests will be authenticated via public key infrastructure.  The client side will be a contact management application, integrated with the email, news, and chat clients, among others.

The contact management application, and the associated server-based data store, will provide the unified infrastructure to manage contacts and associated permissions for anything and everything.  This greatly lessens the barriers to entry for social software of all kinds.  Since this sensitive data is totally under the user's control (perhaps at an ISP, perhaps in a server on their desktop, or locked in a closet at home), privacy concerns are somewhat lessened.

The Semantic Web community has produced tools for aggregation and semantic analysis, and these show great promise.  While these and similar add-on tools will provide value to users, we should not forget about the end-user software that creates the data and makes it available.  This end-user software will be used for far more than feeding aggregators.  Done well, it will be invaluable to the user in its own right.

The described architecture involves foaf-specific nameservers, foaf servers, and clients.  In a terse bullet format are described some requirements of each, and some possible applications to use this infrastructure.

foafnameserver requirements

• relatively few in number, well-known, highly available
• perhaps a new DNS record would point to them, similar to MX
• given an mbox, return one or more FOAF URLs

foafserver requirements

• deployed similarly to SMTP/IMAP servers; corporate internal instances in IT's server rooms, some at ISPs, some on always-on desktops, few if any on low-availability machines
• rich permissions model control access for people, groups (local and external)
  • control access to FOAF data, down to RDF triple if desired
  • hierarchial (or directed acyclic?), with the first-level entity being a person, group, company, event, etc.  child nodes would be assertions & etc. about the first-level thing being described
  • access choices of:
    • visible to self
    • visible to <friend>
    • visible to friends of <friend>
    • visible to friends of friends of <friend> (?? bit silly, really)
    • visible to world
    • ("visible to everyone except <group>" is a rathole, don't go there)
  • good UI and sensible defaults are essential to making this usable
• interface presented to the public:
  • accept a request for an mbox's FOAF data
    • request may be PK authenticated as coming from <mbox>
    • request may come with certificate that a friend of yours knows <mbox>, or a friend of a friend knows them, etc.
  • return the subset of FOAF info determined to be visible to the requester
  • queue requests for reciprocal foaf:knows links
    • (someone else is asking you "will you be my friend?")
• interface presented to the user's clients:
  • canonical storage for user's FOAF data
  • manage access permissions on that data
  • respond to requests for reciprocal foaf:knows links
  • clients can create a new child entity that is access-controlled, akin to a RDF triple (or subtree of them), just below the first-level thing being described in the RDF hierarchy
    • example: your alarm clock could create an attribute about you, "wakefulness", to report "asleep until <time>"/"been hitting snooze since <time>"/"seems to be awake since <time>"/"no data". you probably don't want to share that information with many people, but perhaps your phone would use it to send calls directly to voicemail until you woke up.  your phone would (using its own access list, stored on the foafserver) know who could bypass voicemail and wake you
    • example: your online games could create an attribute about you, "what online multiplayer game you're currently playing, if any", and the permissions on that attribute might be set such that it's only visible to your gaming friends

client requirements

• write-through cache of user's FOAF data
• multiple clients may create, read, and modify data: home pc, work pc, pda, phone, home phone/voicemail
• cache other important FOAF data, for speed and availability

client applications

• contact management app
  • manages foaf:knows/groups/permissions on foafserver
  • manage details of invitations to exchange foaf:knows links
    • negotiate attributes of, and permissions limiting visibility of, data attached to local user's profile, and other user's profile
• send invitation to exchange foaf:knows links
  • put this feature in many/most clients, in full or abbreviated form
  • optionally, rather than sending the invitation immediately, store a bookmark on the foafserver for later consideration
  • example: web browser notices FOAF files (or href link to one), gives the option of bookmarking or befriending. (similar to how a web browser treats mailto: links)
• email client displays headshot of message sender along with message
• email client displays online status of message sender (chat client, online game, phone, as determined by screensaver, as determined by TV, whatever)
• email client sends message in recipient's preferred format (as reported in their profile) if possible: plain/html/rtf; preferred charset, etc.
• home phone/answering machine uses callerid to find and display additional data about the caller before you answer, while you're speaking, or while/before you're listening to the message
• manage email lists and other groups
  • as a first-class entity on the foafserver, the email list entity itself could have a profile, foaf:know people, etc.
  • the membership information on the foafserver would just be a copy of that already managed by the listserver, so the listserver would manage list membership, conduct polls, conduct polls on prospective members, etc.
• calendar server
  • uses foafserver's permissions info to control who can see what on your calendar, and who can send you invitations for which time slots
  • create an event
    • an event would be an entity on the calendar server, but also be a first-class entity on the foafserver to manage access permissions and contacts
      • the event could therefore foaf:know people; the entry could be deleted after the event, or retained to give the attendees a way to find each other again if they so choose
    • calendar server would handle invitations, reminders, status updates, request information, limit invitations, advise mortal enemies of their impending potential proximity, advise the event organizers of the projected demographics of the event participants, etc.
  • publish an event to the public, notify subscribers of your publicly-visible calendar entry via email/atom/rss, and public web page
  • notify some subset of your friends that you'll be attending an event (which has a publicly-visible calendar entry)
    • example: you're going to a show, so the official event is linked to on your calendar. perhaps you create another event on your calendar representing your group attending the show together, possibly including pre- and post-event activities, locations, and times. your calendar server manages invitations, attendance notification, etc.
  • notify some subset of your contacts that you're interested in an event; if enough people express an interest perhaps you'll go as a group.

log contacts

• examples: cell phone call logs, home answering machine callerID/datetime/callduration record
• possibly make the/a "main" client be the repository for this, to avoid potentially storing this very sensitive data at an ISP. does this mean that the "main" client implements some of the foafserver protocol?
• mailman enhancement to generate and serve FOAF for email list, saying the list foaf:knows each member and vice versa (ditto for listserv, etc.)
  • each member should be able to choose if their name is to be visible globally, or only to members of the list, or not at all

spam considerations

• spammers will love FOAF, as publicly-available FOAF data defeats whitelists in their present form. those who use them will need better whitelists, perhaps using part of the received: sequence (or other header data) as a signature.  SPF (Sender Permitted From) or similar should also defeat this "sheep's clothing" spam, for those domains that implement it.