11September
In comments to our last post on this subject, Mr. Pokery wrote,
I don't yet see why you can't both be right simultaneously.We would certainly hope that it is possible for Mr. Fitzpatrick's model to adopt elements proposed here. The underlying point on centralisation versus distribution is this: while it may be more convenient to store all the data at the central server end, the design must not assume this is inevitable, and the implementation must allow people to declare their own relationships independently of the central server, including the ability to declare that there is no data. A centralised server should be seen, at least on a philosophical level, as a bodge to be improved in a subsequent release.
One can (at the risk of being a party bore) draw an analogy with the perversion of YADIS on Livejournal: there is no way for customers to declare their own identity server independent of the current owners', and (officially) no way to declare that they have no distributed identity. Only under these conditions is it possible to coerce people into yielding their identity. This sort of thing stinks, and any sensible system would design around it.
Tied into this: it should be possible to maintain the underlying data by hand. Not advisible, not the way 99.999% of people will run it, but possible. For all intents and purposes, YADIS is too complex for the vast majority of people to create their own instance. FOAF files can be understood and written by anyone who understands a little English. Keeping it simple helps to prevent against co-option by big business.
Context Management is a very valid point; partitioning the data into various sets, with complete knowledge assumed within each set, directional knowledge (or lack of knowledge) assumed outside those sets. For not entirely disreputable reasons, Mr. Fitzpatrick has ducked this matter in his initial draft, only covering data that one is content to share publicly.
Some form of authentication would be required; off the back of an envelope, it may be necessary to piggy-back on a site's existing authentication mechanism. The Section 1 could be a bit like this
-- Public declarations * On the BBC, I am daWeaver * On Iziblog, I am daweaver -- Semi-public declarations * See also: http://foaf.oldkidstv.rpg/~userhash/
... the link taking you to a secure Section 1 and 2 declaration giving relationships on OKTV. For this back of an envelope model, we can't see how to allow the public to discover relationships they may be able to see without disclosing the existance of that relationship. Such things may be possible via a third party, but that militates against the complete transparency we propose.
Livejournal's contact groups are a decent example of this segmentation, and may prove fruitful, at least as a starting point.
I don't want all my work colleagues on VerySeriousBusinesslikeSpaceBook knowing that I exist on anything other than said VSBSB
This is somewhat more simple: when signing up, leave the FOAF box on VSBSB blank. You don't want people on VSBSB to be able to link you to anything else, so you must have the option to explicitly state that there are no connections. Enforcing a complete opt-out relies on the integrity of big business, a lost cause where Six Apart is concerned, but if there is no way to link you to another database, that may be sufficient. We get the feeling that we're missing something here, such as Mr. Pokery's point...
I think it would be a strongly desirable feature to have to ensure that the user can set asymmetric information permission should they so desire.
No disagreement from this corner. The first bite, the proof of concept, will almost certainly have to be fully public data. Getting the basics right is hard: adding in all the permutations of trusted groups is many degrees harder. Public data feels like a problem that can be solved in P. Non-public data feels like a problem that is NP-complete.
