Notes For Implementation

The following narrative and discussion covers the things that I've been thinking about regarding how I think the Sygn system should be implemented. I'm just talking out-loud here in hopes of inspiring someone, so I'm open to solutions. --tychoish

I'm am not (primarily) a technology developer, so my ability to itemize all of the specific requirements here are limited. I've also included in this section of the specifications personal eccentricities about these sorts of things. This section includes my rational for the decisions that I've made, but should also read as a an RFC (request for comment).

• YAML was chosen as a data format because effective parsers and bindings exist for most major programing languages (platform agnostic,) and because it is flexible, and terse, while remaining human readable. For data fields which cannot have spaces, I prefer hyphens to underscores for separating words.

• PGP signatures were chosen as a method of verifying the both the authenticity of profiles (straightforward decision, it seems to me) and for establishing authority of profiles because the web-of-trust infrastructure already exists, even if it's not well deployed amongst the general public at present. Thus the use of PGP in this context, behind the scenes, raises the deployment possibilities of PGP itself (a good side effect), and it allows us to calculate the authority (eg. number/quality of signatures).

• XML-RPC pings were chosen as a method of notifying aggregating servers, as profile publishers only need to tell aggregating servers that there's been a change to a profile at a given url. The aggregating server then, on it's next refresh knows which profiles have changed, and can fetch those results accordingly. This releases the load on the servers, and allows profile publishers to ensure that the servers can find their profile.

  The more I think about this, the more I think XML-RPC is the wrong answer here. We need some way of giving the ?SygnAggregator the profile-url value. I think it would be good to have a uniform mechanism to allow users to contribute profiles to a number of different ?SygnAggregator instances. A simple REST-like API? I don't think we need to convey anything other than a URL and as long as it works, and is super easy for users (and they can push new profiles to it,) all should be well.

• The system should assume that profiles are licensed in the following manner (to be formalized):

  The creator is the person described in the profile; the aggregator is the operator of the server that collects and publishes the profiles; "published profiles" refers to the collection of profiles publicly published by the aggregator. (Note, published profiles are a subset of the group of the profiles submitted to the server.)

  Copyright is assumed, unless otherwise specified, to be sole property of the creator of the profile. Third party aggregates of profiles are granted a license to republish profiles, under the condition that the agregators provide access to a source file(s) (in YAML) for all of the profiles published publicly. If the source is not published within 30 days, the aggregator has violated the copyright of every profile distributed by the aggregator, and is liable for that risk.

  Furthermore, aggregating servers may filter (eg. select publication) submitted profiles using whatever method they like (including by hand,); however, the decision to display or not display any field in the profiles must be accomplished pragmatically, or the aggregator is considered to have violated the license for all profiles. (Eg. Aggregators have full control over which profiles they publish, but cannot choose to publish some fields for some profiles, but remove those fields from other profiles. If the aggreator tampers with some profiles by hand, the aggregator has violated the license for all profiles published.)

• Notes on the server implementation.

  • Distributing the aggregating servers allows the community to generate lists/databases using the same/overlapping collections of data, and then creating specific lists of value to their audience. For instance, the GIMP Project (as an example) should be able to run their own server on which their members can ping to publish profiles.

  • Servers should allow operators to filter output in order to create more meaningful lists. For instance, the GIMP project might alternately choose to pull the data collected by an upstream aggregator, and only publish entries belonging to users who's public keys had two or more signatures, and who listed "the-gimp" under free-software.projects.

  • Operators of servers are not required to publish all profiles that they receive pings for, and should be able to drop spam and other irrelevant profiles on the floor during parsing at the operator's discretion.

  • While I can imagine instances in alternate problem spaces where server operators may want to avoid publishing source for aggregate data, server implementations should make output in yaml format available by default. (ie. in situations where date is put into a SQLite, MongoDB, CouchDB for )

  The thirty day period exists so that in situations where the source file is large, the server operators wouldn't need to dynamically regenerate the text file on every refresh.

  This lets sub-servers publish a collection of profiles that represent a subset of other larger servers' collection, for specific audiences.

  • The server implementations should conform to the terms and ideals of the copyright described above.